Re: [IndexedDB] What happens when the version changes?

On Tue, May 18, 2010 at 9:36 PM, Shawn Wilsher <sdwilsh@mozilla.com> wrote:

> On 5/18/2010 1:02 PM, Nikunj Mehta wrote:
>
>> A database connection that locks the entire database cannot be opened if
>> there is another database connection that locks at least one database
>> object, e.g., an index or object store.
>>
> So basically, as long as some connection holds a database lock, you won't
> be able to do any upgrade.
>

Sure, but this is true of Jonas' proposal as well.


On Tue, May 18, 2010 at 8:30 PM, Nikunj Mehta <nikunj@o-micron.com> wrote:
>
> Perhaps we could produce an event if the version number changes so that an
> application has an opportunity to deal with that. What would the problem be
> with this approach?
>

The spec would need to mandate that the event would be received by every
open connection.  For the async interface, this would be easy.  But in the
sync interface, we'd need to either run the event synchronously in a nested
fashion (which isn't unheard-of, but I believe we avoid whenever possible
for good reason) or throw an exception (which most developers probably won't
handle correctly).  Neither of which seem like great options.


Nikunj: in your vision of the world, what is the point of the version
parameter?  It seems like it could be easily emulated by a value in an
objectStore.  And, if you're assuming that developers will "through a
library develop sophisticated means of performing incompatible changes
without breaking applications using an earlier version of the indexedDB"
then it seems pretty easy for such a library to also keep track of
versioning data in a special objectStore.

Of course, that position is also basically saying that any user of this API
will either need to roll complex coordination code themselves, use a complex
(under the hood) library, or else their code will probably be racy.
 Although we expect many users to use libraries to simplify things like
joins, I think essentially requiring _any_ user to use a library is a bit
overboard.


So basically I think I'm with Jonas on this one: setVersion should be
a convenient (but maybe overly-simplistic for some) way to manage schema
changes.  If someone thinks it's too draconian, then they can simply
implement things themselves and leave the version alone (as Nikunj explained
in the thread).  But if we're not going to do what Jonas proposed, then it
seems like worthless API surface area that should be completely removed.

J