Re: [IndexedDB] Bug# 11401 - We should disallow .transaction() from within setVersion transactions

On Tue, May 17, 2011 at 1:26 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Mon, May 16, 2011 at 6:04 PM, Israel Hilerio <israelh@microsoft.com>
> wrote:
> > Pablo explained to me that the main issue with allowing transactions
> > from being created inside a SetVersion handler is identifying which
> > objectstores the new transaction is binding to. That is bug# 11401 [1].
> >
> > Using Jeremy's example:
> > db.setVersion('1').onsuccess(function () {
> >   db.createObjectStore('a');   //objectstore a
> >   trans = db.transaction('a');
> >   db.removeObjectStore('a');
> >   db.createObjectStore('a');   //objecstore a'
> >   trans.objectStore('a').put('foo', 'bar'); });
> >
> > It is unclear which of the two objectstores a or a' is associated with
> > the newly created READ_ONLY transaction inside the setVersion handler.
> > To echo Jeremy's proposal, would it be okay if we were not to support
> > this scenario and just throw and exception.
> >
> > We would like to modify the spec to say something like:
> >
> > IDBDatabase.transaction:
> > Throws an IDBDatabaseException of NOT_ALLOWED_ERR when the
> > transaction() method is called within the onsuccess handler of a
> > setVersion request.
>
> We also need to throw a NOT_ALLWED_ERR if .transaction() is called
> when there is a pending setVersion call. So .transaction() needs to
> throw from the time when .setVersion is called, to the point when the
> "complete" event is fired on the resulting transaction. Otherwise code
> like the following would suffer the same problem as Jeremy describes:
>
> <assume a database with a 'a' objectStore>
> db.setVersion('1').onsuccess = function(a) {
>   db.removeObjectStore('a');
>  db.createObjectStore('a');
> };
> db.transaction(['a'], READ_WRITE).objectStore('a').put('foo', 'bar');
>
> Note that in the above code the .put() call will happen (though not
> complete) before the setVersion transaction starts.
>
> You can construct similar cases when a .transaction() call happens
> between the asynchronous callbacks during a setVersion transaction.
> Hence .transaction() needs to be blocked all until the setVersion
> transaction completes and the "complete" event is fired.
>

All of this sounds good to me.

J