Frederick Cheung

Ah, I'm with you now, it's not actually checking whether foo exists when handling respond_to 'deliver_foo'

Cool, I've been bitten by this one (also with new relic and a databaseless app). Not someone with a checkout of rails handy, but isn't removing the ActiveRecord...

Well I don't thing rails is doing this on purpose - it's basically doing

  foos << Foo.find(ids)

and find uniques the ids (ie it's not the association code...

You will occasionally get duplicate values but that happened with the old hash too and is inevitable (pigeon hole principal etc.)

I'm assuming no-one actually cares what the actual value of Fixture.identify('foo') is, as long as it doesn't change across test runs - I don't think changing t...

Part of the problem is that the integer overflows, and according to the c standard an overflowing signed integer has undefined behaviour, so this may be harder ...

You're going to get a lot of collisions like that eg

'foo'.sum == 'oof'.sum

If we truly need fixture identifiers that persist across runs, i think that taking t...

Well in the brief experiment I did stuff from lib is reloaded between requests (at least by default).

In development mode your source is reloaded before every request (but the initializer isn't re-run) so you lose the fact that the value has been set.

been there, done that got the tshirt (there was also a thread on the core list a while back proposing that select => 'foo.*' be the default). find default :sele...