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: Israel Hilerio <israelh@microsoft.com>
Date: Thu, 26 Jan 2012 01:23:11 +0000
To: "Jonas Sicking (jonas@sicking.cc)" <jonas@sicking.cc>
CC: "public-webapps@w3.org" <public-webapps@w3.org>, Victor Ngo <vicngo@microsoft.com>
Message-ID: <F695AF7AA77CC745A271AD0F61BBC61E4281ADE3@TK5EX14MBXC113.redmond.corp.microsoft.com>
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.

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.  That implies we'll need to remove this line from the spec.

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.

Received on Thursday, 26 January 2012 01:23:45 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:38 UTC