W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2010

Re: [IndexedDB] Explicitly stablishing the timing of clone creation

From: Pablo Castro <Pablo.Castro@microsoft.com>
Date: Tue, 5 Oct 2010 02:21:28 +0000
To: "public-webapps@w3.org" <public-webapps@w3.org>
Message-ID: <F753B2C401114141B426DB383C8885E05E90EE41@TK5EX14MBXC128.redmond.corp.microsoft.com>

On Mon, Aug 16, 2010 at 12:11 AM, Jonas Sicking <jonas@sicking.cc> wrote:

>>
>> > On Fri, Aug 13, 2010 at 1:43 PM, Pablo Castro
>> > <Pablo.Castro@microsoft.com> wrote:
>> > > 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. Wouldn't
>> > it be more reasonable to require implementations to always create a clone of
>> > the object before returning (i.e. synchronously) and perform the rest of the
>> > operation asynchronously?
>> >
>> > Yes.
>> >
>> > > If we agree on this I'll file a bug and later follow up with some text
>> > for the spec.
>> >
>> > Please do.
>> >
>>
>> Agreed.

Closing the loop on this one. Proposed text is below, any feedback is welcome. I also updated the bug with it.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10381

Thanks
-pablo


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.
Received on Tuesday, 5 October 2010 02:22:08 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:41 GMT