#527 ✓resolved
Mirko Froehlich

Unable to save updated parent object in many-to-one association

Reported by Mirko Froehlich | August 15th, 2008 @ 07:28 PM

I have two models, Foo and Bar, which are defined something like this:

class Foo
  belongs_to :bar

class Bar
  property :dummy, String

  has 0..n, :foos

I now create the following objects:

foo = Foo.create
foo.bar = Bar.create

So far, so good. Now I update one of bar's properties and attempto to save it (via the proxy object on foo):

foo.bar.dummy = 'whatever'

The save call returns true, but nothing is actually saved to the db. If I replace save with save!, the update succeeds.

The code responsible for this behavior seems to be in "many_to_one.rb", inside Proxy#save. The second line in this method reads like this:

return true unless parent.new_record?

Since bar is not a new record in my scenario, this line causes save to immediately exit with true, rather than performing the actual update.

When I remove this line, my scenario works like it should. All my other DataMapper specs still pass as well. However, it looks like "many_to_many_spec.rb" specifically checks for ther current behavior in the "when the parent is not a new record" describe block.

If this is by design, how are associated objects supposed to be saved?

Comments and changes to this ticket

  • Ewout

    Ewout August 21st, 2008 @ 10:07 AM

    You can always save associated objects by saving the parent, if you have kept a reference to it. When saving the parent's children in a OneToMany::Proxy, this kind of check is not performed.

    As to the reason of this check: it is to prevent double work and cycles. IF you would comment this line and run http://pastie.org/257273, you would get infinite recursion.

    Trying to manufacture this example, I stumbled upon a cycle problem that exists in the current datamapper edge with self relationships: http://pastie.org/257261

    This code results in infinite recursion. Resource#save would need some kind of cycle detection to prevent this from happening.

    Anyone an idea how we could tackle the double-work and cycle problems properly?

  • Deleted User

    Deleted User October 24th, 2008 @ 03:18 AM

    The many-to-one part of this isn't needed to illustrate this problem - only the belongs_to in the Foo class (so the has 0..n, :foos declaration in Bar can be removed).

    ...and you cannot save the associated object (bar) by saving the parent (foo) in this case, so if you do:

    foo.bar.dummy = 'whatever' foo.save

    dummy will not be updated to 'whatever'.

  • Dan Kubb (dkubb)

    Dan Kubb (dkubb) January 8th, 2009 @ 05:07 AM

    • State changed from “new” to “accepted”
    • Assigned user changed from “Sam Smoot” to “Dan Kubb (dkubb)”
  • Gary Yngve

    Gary Yngve January 16th, 2009 @ 02:28 PM

    You can do foo.bar.update_attributes(:dummy=>'whatever') to update bar successfully. update_attributes is not overridden by Proxy

  • Dirkjan Bussink

    Dirkjan Bussink January 17th, 2009 @ 07:47 AM

    This issue is already solved in dkubb/dm-core, since the proxy has been completely removed.

  • Jonathan Stott (namelessjon)

    Jonathan Stott (namelessjon) February 22nd, 2009 @ 02:13 PM

    • Tag changed from associations, belongs_to, bug, dm-core to associations, belongs_to, bug, dm-core, one_file_test
    • State changed from “accepted” to “resolved”

    This is fixed in 0.10.0 (see attached test)

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.

New-ticket Create new ticket

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