- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 17 Oct 2011 16:19:37 -0700
- To: Joshua Bell <jsbell@chromium.org>, Cameron McCormack <cam@mcc.id.au>
- Cc: "public-webapps@w3.org" <public-webapps@w3.org>
On Mon, Oct 17, 2011 at 3:15 PM, Joshua Bell <jsbell@chromium.org> wrote: > On Fri, Oct 14, 2011 at 4:02 PM, Israel Hilerio <israelh@microsoft.com> > wrote: >> >> 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 >> > > While this is top-of-mind, is there any desire to eliminate the case of > special passing a string into IDBDatabase.transaction() for the storeNames > parameter, versus a DOMStringList/Array? That case is documented in the > spec, is currently functional in Chrome and has partial test coverage. It > doesn't have the same potentially hidden performance concerns that the [] > shortcut does, but it is a special case and requires pushing interpretation > and validation of the parameter's type from IDL binding into IDB-specific > code. I sort of like the short-cut since it seems like a very common case for web developers to want to create a transaction which only uses a single objectStore. But I agree it's not a huge win for developers as far as typing goes (two characters). I *think* we can move the validation into the IDL binding these days. Something like: interface IDBDatabase { ... transaction(DOMStringList storeNames, optional unsigned short mode); transaction(DOMString[] storeNames, optional unsigned short mode); transaction(DOMString storeNames, optional unsigned short mode); ... } The WebSocket constructor does something similar. cc'ing Cameron to confirm that this is valid. It *might* even be the case that DOMStringList passes as a DOMString[]? But if people really want to get rid of the shortcut I'm not married to it. But it does seem nice :) / Jonas
Received on Monday, 17 October 2011 23:20:40 UTC