- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 28 Jul 2011 10:47:58 -0700
- To: Hans Wennborg <hwennborg@google.com>
- Cc: Webapps WG <public-webapps@w3.org>
On Thu, Jul 28, 2011 at 5:59 AM, Hans Wennborg <hwennborg@google.com> wrote: > On Tue, Jul 12, 2011 at 12:54 AM, Jonas Sicking <jonas@sicking.cc> wrote: >> One possible way to change this is to merge opening a database and >> upgrading it to a given version. Here's what the API would look like: > [...] >> This results in the following >> code: >> >> var req = indexedDB.open("mydatabase", 1); >> req.onupgrade = function(e) { >> var db = e.target.result; >> db.createObjectStore("mystore"); >> <add more objectStores and indexes> >> }; >> req.onsuccess = function(e) { >> var db = e.target.result; >> db.onversionchange = function() { >> db.close(); >> } >> doStuffWith(e.target.result); >> }; >> req.onblocked = function() { >> alert("Another myApp tab is keeping the database open. Please close >> this tab in order to proceed"); >> }; > > It would take a while for us to implement, but this looks nice. > > It's my experience too that people have trouble grasping the > setVersion stuff (and that's even without starting to think about the > pitfalls you describe). > > In particular, I think it's nice if we could get it out of the way > altogether for users who wouldn't ever do schema upgrades, which I > suspect might be a common case. Agreed. > Just to clarify: with your proposal, schema changes can only take > place in the .onupgrade handler of an indexedDB.open() request? The > .onupgrade handler would be called both when no previous database > exists with the requested name, and when one exists, but with a lower > version? That's correct > I'm not sure .onupgrade is the best name... As always, i'm all ears for suggestions. Either way I'm going to start editing this into the spec. We can always change the name if a better one comes up. Thanks a ton everyone for chiming in! / Jonas
Received on Thursday, 28 July 2011 17:48:56 UTC