W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2011

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

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 17 May 2011 00:56:11 -0700
Message-ID: <BANLkTi=zbH=AhSqRhqfK1pvwKTJHzHxh5Q@mail.gmail.com>
To: Israel Hilerio <israelh@microsoft.com>
Cc: "public-webapps@w3.org" <public-webapps@w3.org>
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.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.

/ Jonas
Received on Tuesday, 17 May 2011 07:57:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:19 UTC