Re: [IndexedDB] Behavior of IDBObjectStore.get() and IDBObjectStore.delete() when record doesn't exist

On Mon, Nov 8, 2010 at 4:04 PM, Keean Schupke <keean@fry-it.com> wrote:
> Hi,
>
>>
>> Why do you want to check that a key exists before you delete it? Why
>> not just call delete(key) always and rest assured that it's gone?
>
> because it will throw an exception if the key does not exist...

That is no longer the case, see the first email in this thread :)

>> Similar to Kris, I think worrying about 'undefined' is worrying about
>> an edge case. Simplicity is better than trying to cove every possible
>> edge case.
>
> I thought edge cases are precisely what a specification is supposed to deal
> with.

A spec can never cover 100% of all use cases. Often covering the last
10-20% of the use cases adds as much complexity or API surface, if not
more, as covering the first 80-90%. The trick really is to know when
to stop.

> Anyway, although I don't agree with the other reasons, I find the array case
> compelling. So lets ignore the proposal to disallow storing undefined.
> Perhaps you could add a boolean method "exists(key)" to IDBObjectStore to
> make it easier to tell the two apart.

Note that you can easily do this using openCursor already. In the
synchronous API you could easily implement exists by doing:

IDBObjectStoreSync.prototype.exists = function(key) {
  return this.openCursor(key) !== undefined;
}

I think we should keep exists() in mind for v2 of the interface. It
has other benefits over get() and openCursor() in that if the stored
value is very big it doesn't require time to deserialize it out of the
database. But given how close we are to finishing v1 I'd rather not
add it now. I have added it to my "stuff we should reexamine in v2"
list though.

/ Jonas

Received on Tuesday, 9 November 2010 00:17:31 UTC