On Jan 6, 2:21 pm, Mark Reginald James <[email protected]> wrote:
> 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?
>
Because .first will hit the database and load a fresh copy (if the
collection is not already loaded). I waffled about this a bit a while
ago: http://www.spacevatican.org/2008/11/15/first-foremost-and-0
Fred
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
