Consistent Integer Values Using Fixtures.identify In Ruby1.9

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 the top few bytes from a cryptographic hash (or just reimplement the old hash algorithm from ruby 1.8) would be preferable.

I'd love to see a re-implementation of pre 1.9 String#hash, I'm looking at the bits of C code I pulled from source here.

http://pastie.org/474531

I'm new to C, but I'm playing with converting this to ruby now.

I'm not having a good time hitting the target. Any help?

http://pastie.org/474614

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 than I initially thought

Perhaps better to just switch to a consistent hash or crc value now.

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 this would screw people over. (I'm not even sure why Fixture.identify changing between test runs is a problem - it's only needed to load the fixtures)

@Jeremy Could you give me an example of a crc value? I'm having a hard time thinking of how to get a consistent fixnum representation from a string.

@Frederick Your right, I could care less if this id returned is the same as ruby 1.8. My code is abstract so that I never got bit by this. But I do need consistent values for quite a few reasons.

Again, any implementation help would be appreciated. I might take a stab at this again tomorrow using the bytes somehow.

require 'zlib' Zlib.crc32 "foo" # => 2356372769

OK, here is v2 of the patch. I'm using Zlib like Jeremy suggested. The only problem I ran into is that the default crc32 method could generate a bignum that is out of bounds for my primary keys. So I had to take it down a few notches. I guess it's theoretically possible that some keys could duplicate, but I doubt it would be a problem. Thoughts if any?

I added a few tests that possibly help standardize this internal implementation. All tests pass under 1.9 and 1.8.

I'd hold off on this one too... I'm having issue under the SQL Server adapter since the values might be too big there too.

OK, this one passes all the DB tests, most importantly PostgreSQL.

How about:

MAX_ID = 2 ** 31 - 1
def self.identify(label)
  Zlib.crc32(label.to_s) % MAX_ID
end

Much cleaner! Passes all tests still on all DBs.

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

+1 - the ID generated from a fixture's name should remain consistent across runs, IMO.

I'd consider this ready-to-go. Jeremy can you get it in?

(from [87adecfef59577be17a9731245cb201ecb1b477f]) Reimplement Fixtures.identify so that it consistently generates identities across ruby versions.

[#2633 Consistent Integer Values Using Fixtures.identify In Ruby1.9 state:committed]

Signed-off-by: Jeremy Kemper jeremy@bitsweat.net
http://github.com/rails/rails/commit/87adecfef59577be17a9731245cb20...