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

It sounds like we're all in sync with this new behavior.


These are the various ways in which I see a developer getting a handle to the database object in order to call transaction():

1. Keeping a global reference around after one of the open method handlers is executed (i.e. onupgradeneeded or onsuccess).

2. Accessing it directly from the onupgradeneeded handler

3. Accessing it directly from the onsuccess handler of the open method

The way I see a developer trying to call the transaction method when no VERSION_CHANGE transaction is executed is by doing #1 and closing the db before the call.
Are there other ways I missed?

In order to accommodate this situation, I believe we can change the text to say:

"If the transaction method is called before either the VERSION_CHANGE transaction is committed (i.e. the "complete"

event has *started* firing), or without a database connection being opened, we should throw a InvalidStateError."



Would this be enough?



Israel

On Thursday, January 26, 2012 9:26 AM, Joshua Bell wrote:
On Wed, Jan 25, 2012 at 11:32 PM, Jonas Sicking <jonas@sicking.cc<mailto:jonas@sicking.cc>> wrote:
On Wed, Jan 25, 2012 at 5:23 PM, Israel Hilerio <israelh@microsoft.com<mailto: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<mailto: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