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

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.

/ Jonas

Received on Thursday, 5 August 2010 17:51:03 UTC