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 11947 - [IndexedDB] Updating object stores with auto increment
Summary: [IndexedDB] Updating object stores with auto increment
Status: RESOLVED DUPLICATE of bug 11976
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: Indexed Database API (show other bugs)
Version: unspecified
Hardware: PC Linux
: 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: 2011-02-01 17:54 UTC by Hans Wennborg
Modified: 2011-02-04 10:33 UTC (History)
3 users (show)

See Also:


Attachments

Description Hans Wennborg 2011-02-01 17:54:29 UTC
In 5.1 Object Store Storage Operation, step 1 it says: "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".

But in the object store example in 3.3.3, there is the following:

A second put operation will overwrite the record stored by the first
put operation.
var abraham = {id: 1, name: 'Abraham', number: '2107'};
store.put(abraham);

However, the way I read the specification, the key generator will
generate the key 2, and then set the "id" property in the value to 2.
So this operation does not at all overwrite the first record, and the
next statement in the example: "Now when the object store is read with
the same key, the result is different compared to the object read
earlier." is false.

To me, it would make sense that:

1. If a user provides an explicit key to an operation on an object
store that has a key generator, then the explicit key takes
precedence, and the key generator doesn't do anything.

2. If a user provides an in-line key, then that key takes precedence,
and the key generator doesn't do anything.
Comment 1 Hans Wennborg 2011-02-04 10:33:39 UTC

*** This bug has been marked as a duplicate of bug 11976 ***