- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 25 Jan 2012 23:32:51 -0800
- To: Israel Hilerio <israelh@microsoft.com>
- Cc: "public-webapps@w3.org" <public-webapps@w3.org>, Victor Ngo <vicngo@microsoft.com>
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. > 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 07:34:40 UTC