W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2010

Re: [Bug 11270] New: Interaction between in-line keys and key generators

From: Jeremy Orlow <jorlow@chromium.org>
Date: Sat, 13 Nov 2010 00:05:05 +0300
Message-ID: <AANLkTi=QfV2ZStY_w1BPLzECk0pGBrFHWz5CsjD8fi2w@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Keean Schupke <keean@fry-it.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, Pablo Castro <Pablo.Castro@microsoft.com>, "public-webapps@w3.org" <public-webapps@w3.org>
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 Friday, 12 November 2010 21:05:58 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:42 GMT