[IndexedDB] Asynchronous inline key generation for autoIncrement'ing objectStores

Hi folks,

We've hit a bit of a snag implementing put() for autoIncrement'ing
objectStores when using inline keys. Consider this:

Spec text from http://dev.w3.org/2006/webapi/WebSimpleDB/#dfn-steps-for-storing-a-record-into-an-object-store

  5. If key is not defined or null, then perform the following steps.
    1. Using store's key generator, produce the next key and store it as key.
    2. If store uses in-line keys, then store key as the property
value for object at store's key path.

Sample code from http://dev.w3.org/2006/webapi/WebSimpleDB/#object-store-sync

  var db = indexedDB.open('AddressBook', 'Address Book');
  if (db.version !== '1') {
     var olddb = indexedDB.open('AddressBook', 'Address Book');
     olddb.createObjectStore('Contact', 'id', true);
     olddb.setVersion('1');
  }
  var store = db.openObjectStore('Contact');
  var lincoln = {name: 'Lincoln', number: '7012'};
  var contact = store.put(lincoln);
  // contact.id === 1

The spec and sample code clearly say that the object passed to put()
will be updated so that the object's keyPath property will contain the
newly generated key. This won't work for the async API as we have to
hit the database before we can know which key will be assigned to the
new record.

We propose that the object passed to put() *not* be modified when
using the async API, and we further propose that the keyPath property
be set on the structured clone before storing into the database so
that a subsequent get() call would return a copy of the object with
the keyPath property correctly set. The key assigned to the object
will of course continue to be returned as the result of the success
event fired in response to the put() request.

What do you guys think?

-Ben

Received on Tuesday, 11 May 2010 17:52:17 UTC