- From: Jeremy Orlow <jorlow@chromium.org>
- Date: Thu, 5 Aug 2010 19:03:27 +0100
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Shawn Wilsher <sdwilsh@mozilla.com>, public-webapps WG <public-webapps@w3.org>
- Message-ID: <AANLkTinrz-KtQ3aLp6XD1xrGOLSxLifcu0XaFQ+AeGsH@mail.gmail.com>
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. J
Received on Thursday, 5 August 2010 18:04:17 UTC