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

On Tue, May 11, 2010 at 6:51 PM, ben turner <bent.mozilla@gmail.com> wrote:

> 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?
>

I agree this is a problem and I largely agree with your solution.  My only
concern is performance of cloning data which will (in most cases) not even
be used.  I wonder if the result of put should (instead of being the
structured clone + the generated number) simply be the generated key.  When
the keys are not auto-generated, it'd be undefined.  In the rare case the
person wants to get the rest of the object back, they can subsequently do a
get.

No matter what, I think we shouldn't have the semantics of the sync and
async APIs differ in such a subtle way: if the async API returns a clone +
the generated number as its result, then the sync API should as well (vs.
modifying the object passed in).

J