W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: [IndexedDB] setVersion is cra... is not good

From: Hans Wennborg <hwennborg@google.com>
Date: Thu, 28 Jul 2011 13:59:52 +0100
Message-ID: <CAB8jPhcy_M2WyC1HSu_Prabc=2EibLKbp+S9dTanv9yhDME=uA@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Webapps WG <public-webapps@w3.org>
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.

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? I'm not sure .onupgrade is the best name...

Thanks,
Hans
Received on Saturday, 30 July 2011 11:16:20 GMT

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