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

On Mon, Aug 9, 2010 at 11:21 AM, Pablo Castro
<Pablo.Castro@microsoft.com> wrote:
>
> 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.

I did this. The only change was that I did fire a blocked event. I
don't know why I thought that there wasn't anything to fire it on,
since we do have a request which works great.

/ Jonas

Received on Wednesday, 10 November 2010 00:33:51 UTC