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

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

From: Shawn Wilsher <sdwilsh@mozilla.com>
Date: Thu, 13 May 2010 10:25:54 -0700
Message-ID: <4BEC3622.1040506@mozilla.com>
To: Nikunj Mehta <nikunj@o-micron.com>
CC: public-webapps WG <public-webapps@w3.org>
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).

Cheers,

Shawn



Received on Thursday, 13 May 2010 17:24:50 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:38 GMT