- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 18 May 2010 03:04:12 -0700
- To: Jeremy Orlow <jorlow@chromium.org>
- Cc: Shawn Wilsher <sdwilsh@mozilla.com>, Nikunj Mehta <nikunj@o-micron.com>, public-webapps WG <public-webapps@w3.org>
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. 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. > 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 :) 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. / 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 >> > >
Received on Tuesday, 18 May 2010 10:05:09 UTC