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

On May 18, 2010, at 2:33 PM, Jeremy Orlow wrote:

> 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.

But to me it is a no-op. The spec already does what Jonas is proposing - lock out users when an upgrade is in progress and wait to start an upgrade if a user is using the application.

> 
> 
> 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.

I am not pretending that this is cheap, but then I am not asking that this be in the spec either. I am checking to see if this is useful and worth the cost.

> 
> 
> Nikunj: in your vision of the world, what is the point of the version parameter?

I stated the use case for it in my email that is snipped out in this one:

> As a use case, an application may queue up schema upgrades based on version numbers.

>  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.

Since upgrades are typically performed when an application is started, as opposed to the middle of an application's execution, there needs to be a way for an application to test the database for some abstract representation of what is in the database. Ergo, version. Applications manage the content of the version property (which intentionally is not a number) and use it to the best of their (in)ability.

> 
> 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