Re: [IndexedDB] Implicit transactions

On Wed, Aug 4, 2010 at 7:47 PM, Shawn Wilsher <sdwilsh@mozilla.com> wrote:

>  On 8/4/2010 10:53 AM, Jeremy Orlow wrote:
>
>>
>>
>> Whoa....transaction() is synchronous?!?  Ok, so I guess the entire premise
>> of my question was super confused.  :-)
>>
>>  It is certainly spec'd that way [1].  The locks do not get acquired until
> the first actual bit of work is done though.
>

I fully understand how the trick works.  I just didn't comprehend the fact
that the Mozilla proposal (what's now in the spec) was removing any way to
get into an IDBTransactionEvent handler besides doing an initial data
access.  I wouldn't have agreed to the proposal had I realized this.

Lets say I had the following bit of initialization code in my program:

var myDB = ...
var myObjectStore = myDB.objectStore("someObjectStore");
var myIndex = myObjectStore.index("someIndex");
var anotherObjectStore = myDB.objectStore("anotherObjectStore");

And then I wanted to start a transaction that'd access some key and then
presumably do some other work.  As currently specced, here's what I'd need
to do:

myDB.transaction().objectStore("someObjectStore").index("someIndex").get("someKey").onsuccess(function()
{
    anotherObjectStore.get("someOtherKey").onsuccess(...);
});

vs doing something like this:

myDB.asyncTransaction().onsuccess(function() {
    myIndex.get("someKey").onsuccess(function() {
        anotherObjectStore.get("someOtherKey").onsuccess(...);
    });
});

With the former, we actually have more typing and the code is harder to
read.  Sure, when I'm writing short code snipits, the synchronous form can
be more convenient and readable, but forcing this upon every situation is
going to be a hinderance.

Please, lets add back in a transaction method that returns an IDBRequest.

J