On Tue, Oct 05, 2010 at 10:02:28PM +0100, Michael Gundlach wrote: > On Tue, Oct 5, 2010 at 2:43 PM, Jay Pipes <[email protected]> wrote: > > keys) across multiple nodes. A random 32-bit integer would be fine as > long as the generating algorithm produced acceptable collision rates. > > I'm using randint(0, 2^32) atm. The chance of collision is intuitively > something less than 1 in 1000 after adding a million instances. Ed, I > don't see the need for a 128-bit ID when 32 bits almost suffices. > This would be bikeshedding, except that I don't know how to make a > larger-than-32-bit integer work in sqlalchemy without becoming > implementation-specific. I think I read that sqlalchemy has a BIGINT type > that's only usable with mysql, for example. If someone knows how to make > an internal_id column that is 128 bits and happily stores itself in any > mysql backend, I'm fine with 128 bits (and you can argue with Soren about > it :)
This is what strings are for. I don't see any reason for the unique ID to be an integer at the DB layer. It sounds like everyone wants to revisit this, so let's get all these issues into a draft blueprint and we'll have something concrete to discuss at the summit next month. Cheers, Ewan. _______________________________________________ Mailing list: https://launchpad.net/~nova Post to : [email protected] Unsubscribe : https://launchpad.net/~nova More help : https://help.launchpad.net/ListHelp
