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

From: jorlow@google.com [mailto:jorlow@google.com] On Behalf Of Jeremy Orlow
Sent: Friday, August 06, 2010 2:34 AM

>> 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.

This looks good to me too. I agree with still having deleteDatabase return an IDBRequest so the caller can tell when the operation is done.

-pablo

Received on Monday, 9 August 2010 18:22:22 UTC