
Setting a field in an STI subclass wipes out fields in base class
Reported by Gary Yngve | January 14th, 2009 @ 06:24 PM
have a descending class have an additional property.
when doing an update, the query loads the additional property, simultaneously wiping out the values you wanted to change.
a subsequent save works, because this additional property was loaded. (a similar issue affects lazy properties)
see attached repro script (note dm-validations MUST be included)
Comments and changes to this ticket
-
phatmann February 13th, 2009 @ 10:55 AM
- Tag changed from dm-validations, sti, update to dm-validations, fields, lazy, load, sti, update
- Title changed from dm-validations + STI causes updates to fail to Setting a field in an STI subclass wipes out fields in base class
The problem is more basic than originally thought. For example, for an STI model Truck derived from Vehicle, setting a field in Truck wipes out the fields in Vehicle. Here is code that shows the issue:
class Vehicle include DataMapper::Resource property :type, Discriminator property :id, Serial property :brand, String end class Truck < Vehicle property :capacity, Integer end ##### Truck.create(:make=>"Toyota") t=Vehicle.get(1) t.brand="Dodge" f.capacity=1000 puts t.brand # => "Toyota"
To see this issue, the Truck must be loaded via a Vehicle model. This causes the capacity field to not load. Setting the capacity field triggers a lazy load, which wipes out the attributes.
There is no real workaround. You can rig your code so you don't load a Truck via a Vehicle, but the problem is deeper than this, as it comes up in accessing associations that are STI base classes, as well as validating models that are STI base classes. The problem needs to be solved deep inside of DM.
Attached is a second script that shows the problem.
-
phatmann February 13th, 2009 @ 11:47 AM
- Assigned user set to Dan Kubb (dkubb)
-
Dan Kubb (dkubb) February 13th, 2009 @ 05:36 PM
- State changed from unconfirmed to resolved
Both of these scripts pass fine when using dm-core 0.10.0, available here:
http://github.com/datamapper/dm-...
For the second script, which requires dm-validations to be updated to work on 0.10.0, you can grab dm-validations from here.
http://github.com/somebee/dm-mor...
The above fork will be merged into datamapper/dm-more/next once all the dm-more gems pass with 0.10.0. If you'd like to see this happen sooner, please install dm-core 0.10.0, fork this repo and run rake spec to see what's broken.. submit pull requests to sombee or myself (or ask sombee for commit access).
Marking this as resolved. If the problem persists using the code above, please comment in this ticket and I will re-open it.
Please Sign in or create a free account to add a new ticket.
With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
People watching this ticket
-
Alex Coles
-
Balint Erdi
-
Bernerd Schaefer
-
Carl Lerche
-
Dan Kubb (dkubb)
-
David Leal
-
Dirkjan Bussink
-
Gary Yngve
-
geemus (Wesley Beary)
-
Guy van den Berg (guyvdb)
-
Jamie Macey
-
Jonathan Stott (namelessjon)
-
Ken Robertson
-
Lindsay Holmwood
-
Luis Lavena
-
Luke Sutton
-
matthewcford
-
Michael Klishin (antares)
-
Nick Plante
-
Paul Sadauskas (Rando)
-
phatmann
-
Piotr Solnica (solnic)
-
Rein Henrichs
-
Rick
-
Sindre Aarsaether
-
ssmoot (at gmail)
-
tomjmalone (at gmail)
-
Wayne Seguin
-
Yehuda Katz