Re: [IndexedDB] Interaction between transactions and objects that allow multiple operations

Hey folks,

I'm working with Shawn on the Firefox implementation. Here's our idea
as of now, would you all please comment about things you like or
dislike? Hopefully this follows the gist of the comments shared
already.

 interface IndexedDatabaseRequest {
   IDBRequest open(in DOMString name,
                   in DOMString description,
                   in optional boolean modifyDatabase);
 };

 interface IDBDatabaseRequest : IDBDatabase {
   IDBRequest openTransaction(in optional DOMStringList storeNames,
                              in optional unsigned long timeout);
 };

 interface IDBTransactionRequest : IDBTransaction {
   IDBRequest abort();

   IDBRequest commit();

   IDBRequest createObjectStore(in DOMString name,
                                in DOMString keyPath,
                                in optional boolean autoIncrement);

   IDBRequest openObjectStore(in DOMString name,
                              in optional unsigned short mode);

   IDBRequest createIndex(in DOMString name,
                          in DOMString storeName,
                          in DOMString keyPath,
                          in optional boolean unique);

   IDBRequest openIndex(in DOMString name);

   IDBRequest removeObjectStore(in DOMString storeName);

   IDBRequest removeIndex(in DOMString indexName);

   IDBRequest setVersion(in DOMString version);
 };

We've made some additional changes to IDBRequest and actually
specified the success/error events, but they're not really relevant
here and I'll post about them later.

Note that if we go this route then the mode parameter of the
openObjectStore method becomes nearly meaningless since transactions
are currently supposed to exclusively lock the stores and indexes they
access.

As Shawn has said previously we're looking to make the async API as
close to the synchronous API as possible (never allowing anything to
block, of course) to avoid tons of nested functions that will make web
developers' lives harder. To that end we're wondering how much of the
IDBTransactionRequest interface (as written above) can be made
synchronous-like. For instance, we could simply wait to fire the
success callback until we've read some metadata back from the database
file. Then we could make openObjectStore simply return an
IDBObjectStoreRequest instead of another IDBRequest as we would
already know if the object store exists. It would be even simpler if
the caller used the storeNames parameter in the openTransaction call
since we wouldn't call the success callback unless those stores
existed. We could do similar cheats for the other methods.

What do you guys think?

-Ben

Received on Thursday, 6 May 2010 20:40:19 UTC