Why not return the full 64bit ID in an opaque object? Maths and comparing IDs is meaningless anyway.
Cheers, Keean. On 12 November 2010 21:05, Jeremy Orlow <[email protected]> wrote: > On Fri, Nov 12, 2010 at 10:09 PM, Jonas Sicking <[email protected]> wrote: > >> On Fri, Nov 12, 2010 at 12:36 AM, Jeremy Orlow <[email protected]> >> wrote: >> > On Fri, Nov 12, 2010 at 11:27 AM, Keean Schupke <[email protected]> >> wrote: >> >> >> >> You can do it in SQL because tables that hold a reference to an ID can >> >> declare the reference in the schema. I guess without the meta-data to >> do >> >> this it cannot be done. >> > >> > Even in SQL, I'd be very hesitant to do this. >> > >> >> >> >> Why not get the auto-increment to wrap and skip collisions? What about >> >> signed numbers? >> > >> > Exactly. If we're going to support this, let's keep it super simple. >> As >> > Jonas mentioned, it's very unlikely that anyone would hit the 64bit >> limit in >> > legitimate usage, so it's not worth trying to gracefully handle such a >> > situation and adding a lot of surface area. >> >> Indeed. I'd prefer to fail fatally to trying to do something >> complicated and clever here. I'd be surprised if anyone ever ran into >> this issue unintentionally (i.e. when not explicitly testing to see >> what happens). >> >> One way to look at it is that before we run into 2^64 limit, we'll run >> into the limit that javascript can't represent all integers above >> 2^53. So once IDs get above that you basically won't be able to use >> the object store anyway. >> > > Good point. Actually we probably need to spec the limit to be 2^52ish so > that the auto number is never anything greater than what javascript can > address. > > J >
