W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: [indexeddb] What happens after we reach the AutoInc maximum value?

From: Jonas Sicking <jonas@sicking.cc>
Date: Fri, 12 Aug 2011 17:44:41 -0700
Message-ID: <CA+c2ei-w4S-KuH_+wOJFjqJ+wRoUjj3KhtMd0Rq2tW0REnLCag@mail.gmail.com>
To: Israel Hilerio <israelh@microsoft.com>
Cc: "public-webapps@w3.org" <public-webapps@w3.org>, Jim Wordelman <jaword@microsoft.com>, Adam Herchenroether <aherchen@microsoft.com>
On Friday, August 12, 2011, Israel Hilerio <israelh@microsoft.com> wrote:
> Assuming that we've created an object store with the auto-increment flag
set to true, what is the expected behavior when we reach some type of max
auto-increment value?  Do we want to recycle and start again from zero or do
we stop at the largest number and allow duplicates which will generate a
constraint error?
> It seems that if we were to start again from zero and increment the value
every time we find a constraint error, we could reuse the primary key of
previous records that were deleted.
> What are your thoughts?

We talked a lot about this a while back. The emails should still be in
archives, but I don't remember dates or subjects. Bing is your friend ;-)

Basically this is almost exclusively a theoretical problem. For normal use
the sun will engulf earth before we run out of numbers :-)

For the problem to arise someone will have to insert a very high number that
did not originate from another object store.

The conclusion we had was that if we bump up against the limit of 64bits, we
should simply make it impossible to insert more rows into the object store.
If a page wants to deal with this situation they'll have to destroy the
object store and create a new one.

Problems actually arise earlier than at the max of 64bits. Once you get into
53 bits you start getting values that JavaScript can't express to to
precision limits. But that too will happen much after civilization as we
know it doesn't exist any more ;-)

/ Jonas
Received on Saturday, 13 August 2011 00:45:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:23 UTC