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

Sounds good to me...

Cheers,
Keean.


On 9 November 2010 00:16, Jonas Sicking <jonas@sicking.cc> wrote:

> 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
>