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

This sounds very similar to the strategy used for WebSQLDatabase.

On Tue, May 18, 2010 at 1:54 AM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Thu, May 13, 2010 at 10:25 AM, Shawn Wilsher <sdwilsh@mozilla.com>
> wrote:
> > On 5/13/2010 7:51 AM, Nikunj Mehta wrote:
> >>
> >> If you search archives you will find a discussion on versioning and that
> >> we gave up on doing version management inside the browser and instead
> leave
> >> it to applications to do their own versioning and upgrades.
> >
> > Right, I'm not saying we should manage it, but I want to make sure we
> don't
> > end up making it very easy for apps to break themselves.  For example:
> > 1) Site A has two different tabs (T1 and T2) open that were loaded such
> that
> > one got a script (T1) with a newer indexedDB version than the other (T2).
> > 2) T1 upgrades the database in a way that T2 now gets a constraint
> violation
> > on every operation (or some other error due to the database changing).
> >
> > This could easily happen any time a site changes the version number on
> their
> > database.  As the spec is written right now, there is no way for a site
> to
> > know when the version changes without reopening the database since the
> > version property is a sync getter, implementations would have to load it
> on
> > open and cache it, or come up with some way to update all open databases
> > (not so fun).
>
> I think what we should do is to make it so that a database connection
> is version specific. When you open the database connection (A) the
> implementation remembers what version the database had when it was
> opened. If another database connection (B) changes the version of the
> database, then any requests made to connection A will fail with a
> WRONG_VERSION_ERR error.
>
> The implementation must of course wait for any currently executing
> transactions in any database connection to finish before changing the
> version.
>
> Further the success-callback should likely receive a transaction that
> locks the whole database in order to allow the success callback to
> actually upgrade the database to the new version format. Not until
> this transaction finishes and is committed should new connections be
> allowed to be established. These new connections would see the new
> database version.
>
> / Jonas
>
>