RE: [IndexedDB] Passing an empty array to IDBDatabase.transaction

On Friday, October 14, 2011 3:57 PM, Jonas Sicking wrote:
> On Fri, Oct 14, 2011 at 2:57 PM, Israel Hilerio <israelh@microsoft.com>
> wrote:
> > On Friday, October 14, 2011 2:43 PM, Jonas Sicking wrote:
> >> On Fri, Oct 14, 2011 at 2:27 PM, Israel Hilerio
> >> <israelh@microsoft.com>
> >> wrote:
> >> > On Monday, October 10, 2011 10:15 AM, Israel Hilerio wrote:
> >> >> On Monday, October 10, 2011 9:46 AM, Jonas Sicking wrote:
> >> >> > On Fri, Oct 7, 2011 at 11:51 AM, Israel Hilerio
> >> >> > <israelh@microsoft.com>
> >> >> > wrote:
> >> >> > > On Thursday, October 06, 2011 5:44 PM, Jonas Sicking wrote:
> >> >> > >> Hi All,
> >> >> > >>
> >> >> > >> In both the Firefox and the Chrome implementation you can
> >> >> > >> pass an empty array to IDBDatabase.transaction in order to
> >> >> > >> create a transaction which has a scope that covers all
> >> >> > >> objectStores in the database. I.e. you can do something like:
> >> >> > >>
> >> >> > >> trans = db.transaction([]);
> >> >> > >> trans.objectStore(<any objectstore here>);
> >> >> > >>
> >> >> > >> (Note that this is *not* a dynamic scoped transaction, it's
> >> >> > >> still a static scope that covers the whole database).
> >> >> > >>
> >> >> > >> In other words, these implementations treat the following two
> >> >> > >> lines as
> >> >> > >> equivalent:
> >> >> > >>
> >> >> > >> trans = db.transaction([]);
> >> >> > >> trans = db.transaction(db.objectStoreNames);
> >> >> > >>
> >> >> > >> This, however, is not specified behavior. According to the
> >> >> > >> spec as it is now the transaction should be created with an empty
> scope.
> >> >> > >>
> >> >> > >> I suspect both Mozilla and Google implemented it this way
> >> >> > >> because we had discussions about this syntax on the list.
> >> >> > >> However apparently this syntax never made it into the spec. I
> >> >> > >> don't
> >> recall why.
> >> >> > >>
> >> >> > >> I'm personally not a big fan of this syntax. My concern is
> >> >> > >> that it makes it easier to create a widely scoped transaction
> >> >> > >> which has less ability to run in parallel with other
> >> >> > >> transactions, than to create a transaction with as narrow scope as
> possible.
> >> >> > >> And passing
> >> >> > db.objectStoreNames is always possible.
> >> >> > >>
> >> >> > >> What do people think we should do? Should we add this
> >> >> > >> behavior to the spec? Or are implementations willing to remove it?
> >> >> > >>
> >> >> > >> / Jonas
> >> >> > >>
> >> >> > >
> >> >> > > Our implementation interprets the empty array as an empty scope.
> >> >> > > We
> >> >> > allow the transaction to be created but we throw a NOT_FOUND_ERR
> >> >> > when trying to access any object stores.
> >> >> > > I vote for not having this behavior :-).
> >> >> >
> >> >> > Hi Israel,
> >> >> >
> >> >> > I just realized that I might have misinterpreted your response.
> >> >> >
> >> >> > Are you saying that you think that passing an empty-array should
> >> >> > produce a transaction with an empty scope (like in IEs
> >> >> > implementation and as described by the spec currently), or a
> >> >> > transaction with every objectStore in scope (like in Firefox and
> chrome)?
> >> >> >
> >> >> > / Jonas
> >> >> >
> >> >>
> >> >> We don't do it like FF or chrome.  We create the transaction but
> >> >> it has an empty scope transaction.  Therefore, whenever you try to
> >> >> access an object store we throw an exception.  Based on what Hans
> >> >> said, it seems we're all in agreement.
> >> >>
> >> >> Also, I like Ben's suggestion of not allowing these transactions
> >> >> to be created in the first place and throwing an exception during
> >> >> their
> >> creation.
> >> >>
> >> >> Israel
> >> >>
> >> >
> >> > What type of exception should we throw when trying to create a
> >> > transaction
> >> with an empty scope (NotFoundError, TypeError, or other)?
> >>
> >> Either of those would work for me.
> >>
> >> / Jonas
> >
> > We would like to go with NotFoundError.  The reason is that an empty array
> is still the correct type and therefore a TypeError would seem strange.
> 
> Just noticed "InvalidAccessError" which seems like it could be a good fit too.
> 
> / Jonas
> 

I like that better!  Seems to match closer the reason for the failure.

Israel

Received on Friday, 14 October 2011 23:02:44 UTC