Re: [IndexedDB] IDBObjectStore.delete should accept a KeyRange

On Mon, Oct 24, 2011 at 11:28 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Mon, Oct 24, 2011 at 10:17 AM, Israel Hilerio <israelh@microsoft.com> wrote:
>> On Wednesday, October 12, 2011 2:28 PM, Jonas Sicking wrote:
>>> Currently IDBObjectStore.count/get/openCursor and
>>> IDBIndex.count/get/openCursor/openKeyCursor all take a key or a KeyRange.
>>> However IDBObjectStore.delete only accepts keys. We should fix this to allow
>>> .delete to accept a KeyRange as well.
>>>
>>> / Jonas
>>>
>>
>> This makes sense to me.  Is this something we still want to do?
>
> Yup, I think so. I was just waiting to hear back from others. I'll go
> ahead and make that change to the spec right away.

I made this change. I still kept the difference that .delete(null)
does not work. I.e. it doesn't match, and delete, all records in the
store. It simply seems like it would make it too easy to accidentally
nuke all the data from an object store. We also already have the
.clear() function to do that.

While I was there it did occur to me that the fact that the .delete
function "returns" (through request.result in the async API)
true/false depending on if any records were removed or not might be
bad for performance.

I suspect that this highly depends on the implementation and that in
some implementations knowing if records were deleted will be free and
in others it will be as costly as a .count() and then a .delete(). In
yet others it could depend on if a range, rather than a key, was used,
or if the objectStore has indexes which might need updating.

Ultimately I don't have a strong preference either way, though it
seems unfortunate to slow down implementations for what likely is a
rare use case.

Let me know what you think.

/ Jonas

Received on Tuesday, 25 October 2011 02:40:30 UTC