Datamapper DataMapper

Comments and changes to this ticket

• 

  Dan Kubb (dkubb) June 17th, 2008 @ 05:16 PM

  • Assigned user changed from “Sam Smoot” to “Dan Kubb (dkubb)”
  • State changed from “new” to “open”
  • Milestone cleared.
• 

  Dan Kubb (dkubb) June 17th, 2008 @ 05:43 PM

  • State changed from “open” to “resolved”

  Thanks for the failing spec, it allowed me to figure out the issue alot more quickly than a stacktrace or a general description.

  This issue should be resolved by the following commit:

  http://github.com/sam/dm-core/co...

  I am closing this ticket for now. If this did not resolve your issue please add a comment and I'll reopen it.

• You flagged this item as spam.
  

  Anthony Williams June 17th, 2008 @ 07:28 PM

  Thanks for the fast response.

  Just tested this out and unfortunately I seem to have uncovered a small problem. The value in the database is being saved correctly, but using #reload on the Resource results in the foreign key attribute being set to nil (still, the database isn't affected unless you call #save again).

  I checked out the previous commit (f7d76ee9) and the problem isn't present there.

  Attached a small diff demonstrating this.

  yard = Yard.create!(:engine => Engine.first)
  yard.engine_id # => Integer
  yard.reload
  yard.engine_id # => nil
  

  • 0002-reload-loses-foreign-key.patch 679 Bytes

• You flagged this item as spam.
  

  Anthony Williams June 17th, 2008 @ 07:38 PM

  I think I've sorted it: Resource#reload calls #reload on each of the associations, and ManyToOne#reload in turn runs replace(nil), which unsets the foreign key.

  I've attached a third patch which reverts ManyToOne#reload to how it was before. This passes fine for me.

• You flagged this item as spam.
  

  Anthony Williams June 17th, 2008 @ 07:42 PM

  Heh... attached a fourth patch (0004) which removes my comments, and adds a unit test to ensure that @parent is set to nil.

  • 0004-reload-fix-with-unit-test.patch 1.7 KB
• 

  Dan Kubb (dkubb) June 18th, 2008 @ 01:30 AM

  • State changed from “resolved” to “open”

  Anthony, I just committed the following fix and some integration specs:

  http://github.com/sam/dm-core/co...

  Can you verify if this fixed the issue for you?

• You flagged this item as spam.
  

  Anthony Williams June 18th, 2008 @ 12:36 PM

  Hi Dan,

  That seems to have fixed it.

  However, I've been fiddling about with one or two association issues today and realised that the spec I submitted yesterday is complete rubbish. Since Proxy doesn't define instance_variable_get, @association.instance_variable_get(:@parent) ends up running on the @parent (via Proxy#method_missing), rather than the proxy itself.

  I've fixed this in my own fork at: http://github.com/anthonyw/dm-co...

  Also followed that up with a correction to my spelling error: http://github.com/anthonyw/dm-co...

  I'm still getting up to speed with forks on Github, but hopefully you should be able to pull in those changes if you're happy with them.

• 

  Dan Kubb (dkubb) June 23rd, 2008 @ 07:02 PM

  • State changed from “open” to “resolved”

  Anthony, I've merged your fork into the master repo and all specs passwed, so I'm closing this ticket.

  Sam, could you set up Anthony (github: anthonyw) with commit rights to the master repos?

• You flagged this item as spam.
  

  Sam Smoot June 23rd, 2008 @ 07:07 PM

  Done.

• You flagged this item as spam.
  

  Michael Aufreiter July 4th, 2008 @ 04:56 AM

  • Tag set to “associations, dm-core”

  There's still something unclear for me.

  m = Machine.new(:serial_number => "BLA123", :machinemodel => Machinemodel.new(:name => "XA2312"))
  m.save
  m.machinemodel_id # => nil
  

  I found out that when using Machinemodel.create instead of .new it works properly.

  m = Machine.new(:serial_number => "BLA123", :machinemodel => Machinemodel.create(:name => "XA2312"))
  m.save
  m.machinemodel_id # => 1
  

  So my question is: What exactly is the difference between .new and .create regarding associations?

  Thanks a lot,

  Michael