This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The spec for the asynchronous "put" and "add" methods in object store as well as "update" in cursors don't explicitly state when clones are created, and can even be read as if clones should be created after the function call returned, when the queued up task is executed. This leads to problems where the clone may be modified after the call to put/add/update happens. Spec needs to be updated to indicate that the actual creation of the clone should happen synchronously while the put/add/update method is running, so the state of the object used to perform the database operation is as it was at the time the call was made, regardless of the timing of the actual execution of the method, timing of the callbacks, etc. Related discussion thread here: http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0501.html
Proposed text changes for this: In section "3.2.5 Object Store", the description for the "add" method says: This method returns immediately and stores the given value in this object store by following the steps for storing a record into an object store with the no-overwrite flag set. If the record can be successfully stored in the object store, then a success event is fired on this method's returned object using the IDBTransactionEvent interface with its result set to the key for the stored record and transaction set to the transaction in which this object store is opened. If a record exists in this object store for the key key parameter, then an error event is fired on this method's returned object with its code set to CONSTRAINT_ERR We should change it to: This method stores the given value in this object store by first synchronously creating a copy of the value following steps 1 through 4 of the algorithm described in 4.2 Object Store Storage steps, then returning immediately and asynchronously performing the remaining steps for the algorithm that actually store the object in the object store, with the no-overwrite flag set. If the record can be successfully stored in the object store, then a success event is fired on this method's returned object using the IDBTransactionEvent interface with its result set to the key for the stored record and transaction set to the transaction in which this object store is opened. If a record exists in this object store for the key key parameter, then an error event is fired on this method's returned object with its code set to CONSTRAINT_ERR. In section "3.2.5 Object Store", the description for the "put" method says: This method returns immediately and stores the given value in this object store by following the steps for storing a record into an object store. If the record can be successfully stored in the object store, then a success event is fired on this method's returned object using the IDBTransactionEvent interface with its result set to the key for the stored record and transaction set to the transaction in which this object store is opened. We should change it to: This method stores the given value in this object store by first synchronously creating a copy of the value following steps 1 through 4 of the algorithm described in 4.2 Object Store Storage steps, then returning immediately and asynchronously performing the remaining steps for the algorithm that actually store the object in the object store. If the record can be successfully stored in the object store, then a success event is fired on this method's returned object using the IDBTransactionEvent interface with its result set to the key for the stored record and transaction set to the transaction in which this object store is opened. In section "3.2.7 Cursor" the description of the "update" method says: This method returns immediately and sets the value for the record at the cursor's position. We should change it to: This method sets the value for the record at the cursor's position by first synchronously creating a copy of the value using the structured clone algorithm, then returning immediately and asynchronously updating the record in the underlying store.
Are you planning on working on this soon? If not, maybe you should assign it to dave.null@w3.org
I was just looking at the current state of the spec that this is no longer an issue. The current text explicitly separates the creation of clones from the execution of the steps to asynchronously add or update objects, effectively addressing the issue that made us open this bug in the first place. So I'm resolving this.