Re: [IndexedDB] Bug# 11401 - We should disallow .transaction() from within setVersion transactions
On Tue, May 17, 2011 at 1:26 PM, Jonas Sicking wrote:
> On Mon, May 16, 2011 at 6:04 PM, Israel Hilerio
> 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:
>
>
> 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
Re: [IndexedDB] Bug# 11401 - We should disallow .transaction() from within setVersion transactions
On Mon, May 16, 2011 at 6:04 PM, Israel Hilerio 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:
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.
/ Jonas
[IndexedDB] Bug# 11401 - We should disallow .transaction() from within setVersion transactions
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.
Israel
[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=11401
RE: [IndexedDB] Bug#11401 -We should disallow .transaction() from within setVersion transactions
Resending, any comments on this? Israel On Tue, May 3, 2011 at 12:11 PM, Israel Hilerio wrote: > We expect async operations to be queue up and executed in the order in > which they were created. Thus, the request to create a second transaction > inside the onsuccess handler of a setVersion request using a .transaction() > method would fail as long as we were inside a VERSION_CHANGE transaction. > The reason being that the VERSION_CHANGE transaction locks the complete > db. > > It seems we wouldn't want to allow this type of scenario. Do we expect this > to be a realistic scenario? Is there a reason why we wouldn't just throw a > NOT_ALLOWED_ERR. Could we modify the transaction method information > to say something like: > > -->Throws an IDBDatabaseException of NOT_ALLOWED_ERR when the > transaction() method is called within the onsuccess handler of a setVersion > request. > > This would simply the Async model and keep it consistent with the Sync > model. > > Israel > > [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=11401 >
[IndexedDB] Bug#11401 -We should disallow .transaction() from within setVersion transactions
We expect async operations to be queue up and executed in the order in which they were created. Thus, the request to create a second transaction inside the onsuccess handler of a setVersion request using a .transaction() method would fail as long as we were inside a VERSION_CHANGE transaction. The reason being that the VERSION_CHANGE transaction locks the complete db. It seems we wouldn't want to allow this type of scenario. Do we expect this to be a realistic scenario? Is there a reason why we wouldn't just throw a NOT_ALLOWED_ERR. Could we modify the transaction method information to say something like: -->Throws an IDBDatabaseException of NOT_ALLOWED_ERR when the transaction() method is called within the onsuccess handler of a setVersion request. This would simply the Async model and keep it consistent with the Sync model. Israel [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=11401
