- From: ben turner <bent.mozilla@gmail.com>
- Date: Tue, 11 May 2010 10:51:43 -0700
- To: public-webapps WG <public-webapps@w3.org>
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