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

On Thu, May 6, 2010 at 8:25 PM, ben turner <bent.mozilla@gmail.com> wrote:

> 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?
>

I don't see any major problems with making the open and create methods
synchronous.  It doesn't seem like this would limit UAs  or future
improvements to the spec too much.  Intuitively, setVersion and the remove
methods seem more dangerous though.  And since they're a lot less on the
common path for web developers, I'd lean towards leaving them as is.

Btw, if we go with dynamic transactions only (as Pablo was thinking about
proposing [1]) then we could also make starting a transaction asynchronous.

Unfortunately, none of this makes fetching entries (whether via .get or
a cursor) any easier.  And, since any fetch could possibly need to go to
disk, I don't see any easy way around that.  Which is a big deal since
reading data is probably one of the most common tasks for a database.
 Especially one without joins built in.  :-)   Any ideas on how to make this
better?

J

[1] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0272.html