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

Re: [IndexedDB] Need a method to remove a database

From: Jeremy Orlow <jorlow@chromium.org>
Date: Thu, 5 Aug 2010 19:03:27 +0100
Message-ID: <AANLkTinrz-KtQ3aLp6XD1xrGOLSxLifcu0XaFQ+AeGsH@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Shawn Wilsher <sdwilsh@mozilla.com>, public-webapps WG <public-webapps@w3.org>
On Thu, Aug 5, 2010 at 6:50 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Thu, Aug 5, 2010 at 10:22 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> > On Thu, Aug 5, 2010 at 2:30 AM, Jeremy Orlow <jorlow@chromium.org>
> wrote:
> >> On Wed, Aug 4, 2010 at 7:15 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> >>>
> >>> On Wed, Aug 4, 2010 at 2:56 AM, Jeremy Orlow <jorlow@chromium.org>
> wrote:
> >>> > On Tue, Aug 3, 2010 at 11:26 PM, Jonas Sicking <jonas@sicking.cc>
> wrote:
> >>> >>
> >>> >> On Tue, Aug 3, 2010 at 3:20 PM, Shawn Wilsher <sdwilsh@mozilla.com>
> >>> >> wrote:
> >>> >> > Hey all,
> >>> >> >
> >>> >> > Some of the feedback I've been seeing on the web is that there is
> no
> >>> >> > way
> >>> >> > to
> >>> >> > remove a database.  Examples seem to be "web page wants to allow
> the
> >>> >> > user to
> >>> >> > remove the data they stored".  A site can almost accomplish this
> now
> >>> >> > by
> >>> >> > removing all object stores, but we still end up storing some meta
> >>> >> > data
> >>> >> > (version number).  Does this seem like a legit request to
> everyone?
> >>> >>
> >>> >> Sounds legit to me. Feel somewhat embarrassed that I've missed this
> so
> >>> >> far
> >>> >> :)
> >>> >
> >>> > Agreed.
> >>> > What should the semantics be for open database connections?  We could
> do
> >>> > something like setVersion, but I'd just as soon nuke any existing
> >>> > connection
> >>> > (i.e. make all future operations fail).  This seems reasonable since
> the
> >>> > reasons we didn't do this for setVersion (data loss) don't really
> seem
> >>> > to
> >>> > apply here.
> >>>
> >>> Actually, there could dataloss apply here. Consider a page which
> >>> creates a temporary database, fills it with data, and then slowly
> >>> sends it to the server. Once all data has been sent to the server the
> >>> database is removed.
> >>>
> >>> If you have two instances of that page open, one could remove the
> >>> database while the other is still writing to it.
> >>>
> >>> Though this seems like a pretty scary setup anyway since if the user
> >>> closes the second page midway through, the first one will succeed in
> >>> deleting the database no matter what.
> >>
> >> Well, presumably the site won't delete a database programmatically if it
> >> still has important information in it.  I mean, the same scenario you
> just
> >> explained could happen with .clear() or .removeObjectStore() as well.
> >
> > It can with .clear(), but it can't with .removeObjectStore() since you
> > can only call that when you have a VERSION_CHANGE transaction, which
> > you can only get once no other connections to the database exist.
>
> Actually, using responsible programming it can't happen with .clear()
> either since you can only call that from a READ_WRITE transaction that
> holds a lock on the given objectStore. So if you implement my example
> as:
>
> trans = db.transaction(["mystore"], READ_WRITE);
> trans.objectStore("mystore").openCursor().onsuccess = function(e) {
>  cursor = e.result;
>  if (!cursor) {
>    // we're done, clear the store
>    trans.objectStore("mystore").clear();
>    return;
>  }
>  xhr = new XMLHttpRequest();
>  xhr.open("POST", uri);
>  xhr.send(cursor.value);
>  cursor.continue();
> }
>
> The only way .clear() could cause dataloss in the example I gave is if
> you end your transaction after having sent all the data, and then open
> a new transaction to clear the store.
>
> I suggest we make removeDatabase (or whatever we call it) schedule a
> database to be deleted, but doesn't actually delete it until all
> existing connections to it are closed (though either explicit calls to
> IDBDatabase.close(), or through the tab being closed).
>
> Any calls to IDBFactory.open with the same name will hold the callback
> until the removeDatabase() operation is finished. I.e. after all
> existing connections are closed and the database is removed.
>
> This is similar to how setVersion works.
>

If we're not going to keep it simple, then we should match the setVersion
semantics as much as is possible.  I.e. add the blocked event and stuff like
that.

J
Received on Thursday, 5 August 2010 18:04:17 GMT

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