W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2010

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

From: Jeremy Orlow <jorlow@chromium.org>
Date: Tue, 18 May 2010 10:42:04 +0100
Message-ID: <AANLkTil81O9D_ggiX16RjDi_ya_m0Jbg2fLOCjBSpoPy@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Shawn Wilsher <sdwilsh@mozilla.com>, Nikunj Mehta <nikunj@o-micron.com>, public-webapps WG <public-webapps@w3.org>
What happens to existing connections that were opened against the original
database version (once the DB has been updated)?

Are we sure that having versions is really a v1 feature for IndexedDB?

On Tue, May 18, 2010 at 9: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
> 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
Received on Tuesday, 18 May 2010 09:43:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:07 UTC