W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2011

Re: [indexeddb] result attribute for IDBRequest is set to undefined when calling IDBObjectStore.clear()

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 4 May 2011 15:18:09 -0700
Message-ID: <BANLkTikBr2ppREsKKaun3SsfMBVkdtO6Nw@mail.gmail.com>
To: Israel Hilerio <israelh@microsoft.com>
Cc: Jeremy Orlow <jorlow@chromium.org>, "public-webapps@w3.org" <public-webapps@w3.org>
On Wed, May 4, 2011 at 2:57 PM, Israel Hilerio <israelh@microsoft.com> wrote:
> Great, I believe we have consensus. This is the summary of changes we've discussed plus one question/clarification:
>
> 1. IDBDatabase.deleteObjectStore should change to:
> * void deleteObjectStore (in DOMString name) raises (IDBDatabaseException);
>
> 2. IDBDatabase.createObjectStore and IDBDatabase.removeObjectStore will act synchronously and modify IDBDatabase.objectStoreNames.
>
> 3. IDBObjectStore.createIndex and IDBObjectStore.deleteIndex will act synchronously and modify IDBObjectStore.indexNames.
>
> 4. The result value on the IDBRequest returned by IDBFactory.deleteDatabase will be set to undefined when the function executes correctly.
>
> 5. The result value on the IDBRequest returned by IDBObjectStore.clear will be set to undefined when the function executes correctly.

Agreed!

> 6. IDBCursorSync.advance should change to:
> * boolean advance (in int count);
> Returns true if it iterates to a valid position and false if it iterates off of the end.  Also, the result value on the IDBRequest returned by IDBCursor.advance should be the cursor itself if it iterates to a valid position, or null if it iterates off of the end.

Agreed! I just checked in a patch to implement this. So the spec
should now be correct here.

> Additional questions
> -----------------------------
> 7. I don't see in the spec that IDBObjectStoreSync.delete and IDBCursorSync.delete currently return true/false.  I see them both as void functions.  If it was previously agreed to have these functions return Booleans, we should update the spec to reflect it.

Indeed. I checked in a fix for the synchronous API.

> 8. Assuming we update the spec with the change above, I believe you're also suggesting we make the following change:
> * The result value on the IDBRequest returned by IDBObjectStore.delete and IDBCursor.delete holds true or false depending on if the value existed or not.

The asynchronous API already returned true/false as needed since the
algorithms defined in section 5 already returned true/false.

> If we feel good about these changes, I can work with Eliot to update the spec.
> Let me know.

Sounds good to me!

/ Jonas
Received on Wednesday, 4 May 2011 22:19:06 GMT

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