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: Fri, 6 Aug 2010 10:33:41 +0100
Message-ID: <AANLkTim7+2Nk+L=HJCX+QawePTwmxJXLiD7fSqYWeOcK@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Pablo Castro <Pablo.Castro@microsoft.com>, Shawn Wilsher <sdwilsh@mozilla.com>, public-webapps WG <public-webapps@w3.org>
On Fri, Aug 6, 2010 at 12:37 AM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Thu, Aug 5, 2010 at 4:02 PM, Pablo Castro <Pablo.Castro@microsoft.com>
> wrote:
> >
> > -----Original Message-----
> > From: public-webapps-request@w3.org [mailto:
> public-webapps-request@w3.org] On Behalf Of Jonas Sicking
> > Sent: Thursday, August 05, 2010 2:12 PM
> >
> >>> >> 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.
> >>>
> >>> The "blocked" event fires on the IDBDatabase object. Do we want to
> >>> require that the database is opened before it can be removed? I don't
> >>> really feel strongly either way.
> >>>
> >>> The other question is if we should fire a "versionchange" event on
> >>> other open IDBDatabases, like setVersion does. Or should we fire a
> >>> "holy hell, your database is about to get nuked!" event? The former
> >>> would keep things simpler since there is just one event to listen to.
> >>> The latter might be more correct.
> >>>
> >>> / Jonas
> >
> > I like the idea of just scheduling the database to be deleted once the
> last connection to it closes, and also preventing any new connection from
> being established once the database has been scheduled for deletion. This
> adds as little surface area as possible to the API.
> >
> > If we find that that's not a good idea for some reason, I wonder if we
> should unify the "versionchange" event and this into a single "stuff
> seriously changed" event where subscribers need to close their handles and
> let go of any assumptions they had about the database. Once they can
> re-open, they need to re-establish all their context (this is already true
> for a version change, we may as well extend it to database deletes and any
> other future big changes to the database schema, options, etc.)
> Here's my proposal, please poke holes in it:
> interface IDBFactory {
>  ...
>  IDBRequest deleteDatabase(in DOMString name);
>  ...
> };
> When deleteDatabase is called, the given database is scheduled for
> deletion. If any IDBDatabase objects are opened to the database fire a
> "versionchange" event on those IDBDatabase objects, with a .version
> set to null. If any calls to IDBFactory.open occur, stall those until
> after this algorithm is finished. Note that this generally won't mean
> that those open calls will fail. They'll generally will receive a
> newly created database instead.
> Once all existing IDBDatabase are closed (implicitly or explicitly),
> the database is removed. At this point any IDBFactory.open calls are
> fulfilled and a "success" event is fired on the returned IDBRequest.
> So no "blocked" event is fired as I'm not sure where to fire it. I'm
> also not sure that this is a big problem. I'm not even sure that
> returning a IDBRequest is worth it. The only value I can see is
> wanting to display to a user when a database is for sure deleted as to
> allow the user to for example safely shut down the computer without
> worrying that sensitive data is still in the database.

All of this sounds good to me.  I'd probably still return an IDBRequest
for consistency and so that the app can get a conformation when it's really
gone.  On success would fire with a "null" result field, I'd think.

Received on Friday, 6 August 2010 09:34:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 13:55:35 UTC