W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2013

Re: [IndexedDB] better way of deleting records

From: Jonas Sicking <jonas@sicking.cc>
Date: Sat, 16 Mar 2013 04:33:08 -0700
Message-ID: <CA+c2ei_O6rCWjvVwHBSZutGW8x1jcTAYpx6R=ft-reHcNPcTAg@mail.gmail.com>
To: Kyaw Tun <kyawtun@yathit.com>
Cc: public-webapps@w3.org
On Tue, Jan 15, 2013 at 7:19 PM, Kyaw Tun <kyawtun@yathit.com> wrote:
> From developer point of view, IDBObjectStore.delete method cannot be used
> directly in most use case, since IDBObjectStore.delete returns undefined.
> IDBObjectStore.delete(random_key) always receives onsuccess event, but
> nothing happen. Currently I use cursor or count method before deleting to
> make sure that it will actually be deleted. My suggestion is
> IDBObjectStore.delete return number of records deleted and
> IDBObjectStore.clear return undefined. Hence IDBObjectStore.clear will take
> optional key or key range.

The tricky situation is that while a count(key) followed by
delete(key) is generally slower than a delete(key) which returned the
number of records deleted, in many implementations it's slower to do a
delete(key) which counts the number of deleted records, than one which
doesn't.

So if we mandated that delete(key) counted the number of records
deleted, that would be a performance hit in cases when the caller
doesn't care about the count.

One option would be to add an argument to .delete(key) which specifies
if the count should be calculated or not. Or introduce a
.deleteWithCount(key) function.

> There is no efficient way to delete records by secondary key or index key.
> IDBIndex do not have delete methods. Currently we have to use openCursor and
> delete one by one. Interestingly again, we cannot delete with more efficient
> openKeyCursor. Deleting from openKeyCursor should be allowed.

I agree that we should make it possible to delete from a key cursor.
We should also make it possible to call .update() on a key cursor.

/ Jonas
Received on Saturday, 16 March 2013 11:34:05 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:58 GMT