Re: [IndexedDB] Implicit transactions

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

>  On 8/4/2010 8:42 AM, Jeremy Orlow wrote:
>
>> In the IndexedDB spec, there are two ways to create a transaction.  One is
>> explicit (by calling IDBDatabase.transaction()) and one is implicit (for
>> example, by calling IDBDatabase.objectStore.get("someKey")).  I have
>> questions about the latter, but before bringing these up, I think it might
>> be best to give a bit of background (as I understand it) to make sure
>> we're
>> all on the same page:
>>
>>  If I recall correctly, the original proposal from us basically said that
> IDBDatabase.objectStore("foo", [mode]) was just a shortcut for
> IDBDatabase.transaction("foo", [mode]).getObjectStore("foo");  I'm not sure
> if putting some text like that would help make things clearer though.
>

Whoa....transaction() is synchronous?!?  Ok, so I guess the entire premise
of my question was super confused.  :-)

....But I'm not sure I like that at all since it means that I will have to
open at least one object store every time I do any transaction.  I.e. I
can't save my favorite object stores and indexes to variables and then use
them freely within transactions, which is something I expect most users will
want want to do.

Having a cute shortcut to cut down on one async call per transaction might
be a good idea.  But forcing me to call .objectStore() (and possibly
.index() or others) for the first operation of every transaction seems
sub-optimal.  I can double check with some "real" web developers around
Google, but I'm pretty sure they'll much rather make an asynchronous call to
start a transaction to get back execution within an IDBTransactionEvent
context rather than having to do repeated objectStore() and .index() calls
to start every single transaction.

And the more I think about this, the more I'm skeptical that any sort
of synchronous transaction starting code is worth the complicated semantics.
 I mean, in reality, it saves very little code.  And although it makes
sample code a bit prettier to look at (I believe this was one of the
original selling points), I think it's going to confuse developers more than
it'll help them--in the long run.

J