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

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

> On Tue, May 18, 2010 at 2:42 AM, Jeremy Orlow <jorlow@chromium.org> wrote:
> > What happens to existing connections that were opened against the
> original
> > database version (once the DB has been updated)?
>
> Once a call to setVersion() has happened, any existing connections
> will forever fail all requests with a WRONG_VERSION_ERR.


Ahh!  Got it.


> I guess you
> could argue that if the upgrade transaction is rolled back then we
> could "reenable" existing connections. However this just seems to be
> an optimization for an edge case and just adds needless complexity, so
> I don't think we should do it.
>

I don't care all that much, but I don't really see this as adding that much
complexity.  I'd be weakly in favor of an aborted upgrade not requiring
re-connection.

> Are we sure that having versions is really a v1 feature for IndexedDB?
>
> Nothing is set in stone, that's why we're still debating :)
>

Of course.  I was just bringing up the question because this was a feature
in the original spec that has already had a lot of "nice to have" stuff
pruned from it and this seems somewhat borderline for whether it should be
pruned.


> Though what would you propose that a website does if it needs to
> update its database format? You could always hope that the user only
> has one tab open, but that seems scary and risks data corruption.
>

Well, you could leave it up to apps themselves.  But then I suppose they'd
have to check whether the version has been changed every single time they
access the database....which I guess is sub-optimal.  They post a message to
all open windows, use a shared worker, or something else like that to
communicate when a database is being updated....but it'd be complicated to
do this without it being racy....

OK, I'm convinced.  :-)


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