#770 ✓resolved
Gary Yngve

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

    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

    phatmann February 13th, 2009 @ 11:47 AM

    • Assigned user set to “Dan Kubb (dkubb)”
  • 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.