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
end
class Bar
...
property :dummy, String
has 0..n, :foos
end
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'
foo.bar.save
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 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 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) January 8th, 2009 @ 05:07 AM
- State changed from “new” to “accepted”
- Assigned user changed from “Sam Smoot” to “Dan Kubb (dkubb)”
-
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 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) 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.
Create new ticket
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
Dan Kubb (dkubb)
Rick
rupert