W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2012

Re: [indexeddb] Creating transactions inside the oncomplete handler of a VERSION_CHANGE transaction

From: Joshua Bell <jsbell@chromium.org>
Date: Thu, 26 Jan 2012 09:26:26 -0800
Message-ID: <CAD649j7omU9zqKa8_B+qLV1XEmQpgmgLf2PAoPckuuss=4MquA@mail.gmail.com>
To: "public-webapps@w3.org" <public-webapps@w3.org>
Cc: Victor Ngo <vicngo@microsoft.com>
On Wed, Jan 25, 2012 at 11:32 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Wed, Jan 25, 2012 at 5:23 PM, Israel Hilerio <israelh@microsoft.com>
> wrote:
> > On Wednesday, January 25, 2012 4:26 PM, Jonas Sicking wrote:
> >> On Wed, Jan 25, 2012 at 3:40 PM, Israel Hilerio <israelh@microsoft.com>
> >> wrote:
> >> > Should we allow the creation of READ_ONLY or READ_WRITE transactions
> >> inside the oncomplete event handler of a VERSION_CHANGE transaction?
> >> > IE allows this behavior today.  However, we noticed that FF's nightly
> >> doesn't.
> >>
> >> Yeah, it'd make sense to me to allow this.
> >>
> >> > In either case, we should define this behavior in the spec.
> >>
> >> Agreed. I can't even find anything in the spec that says that calling
> the
> >> transaction() function should fail if you call it while the
> VERSION_CHANGE
> >> transaction is still running.
> >>
> >> I think we should spec that if transaction() is called before either the
> >> VERSION_CHANGE transaction is committed (i.e. the "complete" event has
> >> *started* firing), or the "success" event has *started* firing on the
> >> IDBRequest returned from .open, we should throw a InvalidStateError.
> >>
> >> Does this sound good?
> >>
> >> / Jonas
> >
> > Just to make sure we understood you correctly!
> >
> > We looked again at the spec and noticed that the IDBDatabase.transaction
> method says the following:
> > * This method must throw a DOMException of type InvalidStateError if
> called before the success event for an open call has been dispatched.
>
> Ah! There it is! I thought we had something but couldn't find it as I
> was just looking at the exception table. That explains Firefox
> behavior then.
>
> > This implies that we're not allowed to open a new transaction inside the
> oncomplete event handler of the VERSION_CHANGE transaction.
> > From your statement above, it seems you agree with IE's behavior which
> negates this statement.
>
> Yup. Though given that the spec does in fact explicitly state a
> behavior we should also get an ok from Google to change that behavior.


We're fine with this spec change for Chromium; we match the IE behavior
already. (Many of our tests do database setup in the VERSION_CHANGE
transaction and run the actual tests starting in its oncomplete callback,
creating a fresh READ_WRITE transaction.)


> > That implies we'll need to remove this line from the spec.
>
> Well.. I'd say we need to change it rather than remove it.
>
> > Also, we'll have to remove the last part of your proposed statement to
> something like:
> > If the transaction method is called before the VERSION_CHANGE
> transaction is committed (i.e. the "complete" event has *started* firing),
> we should throw an InvalidStateError exception.  Otherwise, the method
> returns an IDBTransaction object representing the transaction returned by
> the steps above.
>
> We also need to say something about the situation when no
> VERSION_CHANGE transaction is run at all though. That's why I had the
> other part of the statement.
>
> / Jonas
>
>
Received on Thursday, 26 January 2012 17:26:53 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:50 GMT