This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 18558 - [IndexedDB] Define error seen when key generator maximum value is reached
Summary: [IndexedDB] Define error seen when key generator maximum value is reached
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: Indexed Database API (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: This bug has no owner yet - up for the taking
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-08-14 19:25 UTC by Joshua Bell
Modified: 2013-02-20 00:53 UTC (History)
5 users (show)

See Also:


Attachments

Description Joshua Bell 2012-08-14 19:25:28 UTC
The spec says:

"When the current number of a key generator reaches above the value 2^53 (9007199254740992) any attempts to use the key generator to generate a new key will result in an error."

.. but the specifics of the error and how it manifests is not defined.

The logical place would be at the point where the key generator is queried, in the "Object Store Storage Operation":

"If store uses a key generator and key is undefined, set key to the next generated key."

In the Chrome implementation, if the key generator results in an error, the storage operation fails at this point with a DataError.

This can be exercised by:

store = db.createObjectStore('store', {autoIncrement: true});
store.put('a', 9007199254740992);
r = store.put('b');
r.onerror = function(e) { alert(e.target.error.name); };
Comment 1 Jonas Sicking (Not reading bugmail) 2012-08-14 19:45:19 UTC
"DataError" works for me. Firefox currently uses "UnknownError" which I agree is a less good option.
Comment 2 Odin Hørthe Omdal 2012-08-23 09:46:15 UTC
Hmm. We fail with ConstraintError because it's "coming from the database". 

I don't really think DataError is a very good fit based on how it's used in other parts of the spec, dealing more with the data that you put in. This is really something you can't control, it's different from the others.

I'd be okay and change it to DataError if you update the spec to that, no problem. I just think ConstraintError makes a bit more sense :-)
Comment 3 Jonas Sicking (Not reading bugmail) 2012-08-23 10:04:33 UTC
Good point. In fact, DataError isn't used as an error-event anywhere right now, only as an exception thrown when invalid data is provided as input.
Comment 4 Joshua Bell 2012-08-23 15:53:51 UTC
I'm fine with switching Chromium to ConstraintError in this case.
Comment 5 Joshua Bell 2012-12-10 18:29:25 UTC
(In reply to comment #4)
> I'm fine with switching Chromium to ConstraintError in this case.

... and FYI we did switch Chromium over to ConstraintError some time ago.
Comment 6 Eliot Graff 2013-02-20 00:53:14 UTC
Added the following:

In 3.1.13 (7th bullet)
...
When the current number of a key generator reaches above the value 2^53 (9007199254740992) any attempts to use the key generator to generate a new key will result in a ConstraintError. It's still possible to insert records into the object store by specifying an explicit key, however the only way to use a key generator again for the object store is to delete the object store and create a new one. 

In Section 5.1, Object Store Storage Operation
...
2. If store uses a key generator and key is undefined, set key to the next generated key. If store also uses in-line keys, then set the property in value pointed to by store's key path to the new value for key, as shown in the steps to assign a key to a value using a key path. If the current number of a key generator reaches above the value 2^53 (9007199254740992) any attempt to use the key generator to generate a new key fails with a ConstraintError. 

Commit #382