Forum: Rails-core (closed, excessive spam) unintuitive behaviour of AssocationCollection#first

A post on rails-talk led me to worry about the following:

post.comments.first.title = 'Foo'
post.comments.collect &:author #this line isn't really important -
anything that requires loading the collection will do

Ta-da! post.comments.first.title reverts to its old value (because
it's now a different object - the first item of the freshly loaded
collection as opposed to just the result of find :first).
This behaviour is rather unintuitive to me (and I would have thought
conducive to hard to track down bugs) - Thoughts?


Fred

> Ta-da! post.comments.first.title reverts to its old value (because
> it's now a different object - the first item of the freshly loaded
> collection as opposed to just the result of find :first).
> This behaviour is rather unintuitive to me (and I would have thought
> conducive to hard to track down bugs) - Thoughts?

There are a bunch of other corner cases which present themselves when
you start digging in, and  a bunch of error cases to account for when
fixing them.  Putting an identity map in there would solve some of
those problems, but involve a lot of work and handling some additional
errors like StaleObject and AlreadyAttachedObject and all that jazz.

If someone wanted to play around with it in a git branch then we'd
have a better idea about the work involved, for now it's just a vague
sense of foreboding.

--
Cheers

Koz

On 22 Jul 2008, at 10:28, Michael Koziarski wrote:

> those problems, but involve a lot of work and handling some additional
> errors like StaleObject and AlreadyAttachedObject and all that jazz.
>
identity map ?

Fred

> identity map ?

It's a way of guaranteeing that there's only one object with a given
id in a given context:

http://martinfowler.com/eaaCatalog/identityMap.html




--
Cheers

Koz

On 22 Jul 2008, at 10:41, Michael Koziarski wrote:

>
>> identity map ?
>
> It's a way of guaranteeing that there's only one object with a given
> id in a given context:
>
> http://martinfowler.com/eaaCatalog/identityMap.html
>

Ah yes. I had an inkling that might be what you were talking about.
That itself might introduce some subtle differences in behaviour

Fred

> Ah yes. I had an inkling that might be what you were talking about.
> That itself might introduce some subtle differences in behaviour

It introduces huge differences in behaviour for some situations like:

def whatever
  @foo = Foo.find(1)
  # Some other process updates foo 1
  @foos = Foo.find(:all) # do you retain the old data for foo#1 or
replace it with the new data, or raise an exception?
end

The first part of an identity map is easy, it's defining the behaviour
in all the edge cases that makes it hard, :)
--
Cheers

Koz

On 22 Jul 2008, at 10:52, Michael Koziarski wrote:

> replace it with the new data, or raise an exception?
> end
>
> The first part of an identity map is easy, it's defining the behaviour
> in all the edge cases that makes it hard, :)

That's a bit of a bastard :-) It's not even that much of an edge case.

Fred