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

On Wed, May 4, 2011 at 11:04 AM, Israel Hilerio <israelh@microsoft.com> wrote:
> If that is the case we need to ensure that the async implementations for deleteDatabase and deleteObjectStore have consistent results on their IDBRequest.  deleteDatabase stipulates that the result of the request is null and deleteObjectStore stipulates that the result of the request is undefined.  Using your logic they both should return undefined results.

Yes. I think that deleteDatabase should return undefined.
deleteObjectStore should be a synchronous method (per other thread)
returning void and so no return value would need to be defined.

> Furthermore, we should be using this pattern everywhere there is an async function that returns an IDB Request and there is a counterpart sync void function.  That would mean that for each of the following functions the result of the request should be undefined:
> * IDBFactorySync.deleteDatabase --> IDBFactory.deleteDatabase
> * IDBDatabaseSync.deleteObjectStore --> IDBDatabase.deleteObjectStore
> * IDBObjectStoreSync.delete --> IDBObjectStore.delete
> * IDBObjectStoreSync.clear --> IDBObjectStore.clear
> * IDBCursorSync.delete --> IDBCursor.delete

IDBObjectStore(Sync).delete and IDBCursor(Sync).delete currently
return true/false depending on if the value existed or not. I think
that is useful and should remain.

For the other methods I agree that they should return void and so have
no return value at all (or have .result set to undefined in the
asynchronous versions).

Potentially deleteDatabase could return true/false just like
objectStore and cursors. However I can't really come up with any use
cases for this so it might be better to stick with using
void/undefined for now. We can always add a return value later if a
use case arises.

> These functions are okay.  They are both void functions:
> * IDBObjectStoreSync.deleteIndex --> IDBObjectStore.deleteIndex
> * IDBDatabaseSync.close --> IDBDatabase.close
> * IDBCursorSync.advance --> IDBCursor.advance
> * IDBTransactionSync.abort --> IDBTransaction.abort
>
> This one should be okay to because because it has a callback:
> * IDBDatabaseSync.transaction(...)
>
> Do you agree?

Largely yes.

Though looking at cursor.advance, it should behave like
cursor.continue as it provides basically the same functionality. This
means that the asynchronous version should return the cursor itself if
it iterates to a valid position, or null if it iterates off of the
end. The synchronous version should return true if it iterates to a
valid position and false if it iterates off of the end. I think there
are some bugs in the spec currently, both for cursor.advance and
cursor.continue.

Other than that I think you're spot on.

/ Jonas

Received on Wednesday, 4 May 2011 20:35:58 UTC