On Wed, Jan 25, 2012 at 5:23 PM, Israel Hilerio <[email protected]> wrote: > On Wednesday, January 25, 2012 4:26 PM, Jonas Sicking wrote: >> On Wed, Jan 25, 2012 at 3:40 PM, Israel Hilerio <[email protected]> >> 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. > 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
