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

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.

/ Jonas

Received on Thursday, 5 August 2010 23:38:57 UTC