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 <jorlow@chromium.org> wrote: > On Fri, Nov 12, 2010 at 10:09 PM, Jonas Sicking <jonas@sicking.cc> wrote: > >> On Fri, Nov 12, 2010 at 12:36 AM, Jeremy Orlow <jorlow@chromium.org> >> wrote: >> > On Fri, Nov 12, 2010 at 11:27 AM, Keean Schupke <keean@fry-it.com> >> 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 >
Received on Saturday, 13 November 2010 07:59:59 UTC