Frederick Cheung wrote: > Even if it were setting it on the in memory object it wouldn't be in > memory object you think it is. Because a was reloaded, the objects in > a.steps are not the objects b & c (although they do correspond to the > same database rows).
The problem happens before a is reloaded. I just did some experiments with puzzling results. Would you be able to help explain them Fred? Loading development environment (Rails 2.2.2) >> a = Exercise.find(1) => #<Exercise id: 1> >> b = Step.new => #<Step id: nil, exercise_id: nil> >> b.save => true >> c = Step.new => #<Step id: nil, exercise_id: nil> >> c.save => true >> a.steps << b => [#<Step id: 19, exercise_id: 1>] >> a.steps << c => [#<Step id: 19, exercise_id: 1>, #<Step id: 20, exercise_id: 1>] >> b.object_id => 70254505869500 >> a.steps.first.object_id => 70254505813160 >> c.object_id => 70254505838840 >> a.steps.last_object_id => 70254505838840 Why does only the first object in the collection have a different object_id, and why does this difference go away if the empty a.steps is loaded before b is added? Is it a proxy thing? I added a few lines to the has_many code to set the foreign keys on the in-memory records to nil. But because of the above behaviour the fk doesn't change on the local variable that held the first element added to the collection, unless the collection had been pre-loaded. -- Rails Wheels - Find Plugins, List & Sell Plugins - http://railswheels.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
