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

On Thu, Aug 5, 2010 at 11:03 AM, Jeremy Orlow <jorlow@chromium.org> wrote:
> 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.

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

Received on Thursday, 5 August 2010 21:13:05 UTC