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

It would make sense if you make setting a key to undefined semantically
equivalent to deleting the value (and no error if it does not exist), and
return undefined on a get when no such key exists. That way 'undefined'
cannot exist as a value in the object store, and is a safe marker for the
key not existing in that index.


Cheers,
Keean.


On 8 November 2010 17:52, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Mon, Nov 8, 2010 at 8:24 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> > Hi All,
> >
> > One of the things we discussed at TPAC was the fact that
> > IDBObjectStore.get() and IDBObjectStore.delete() currently fire an
> > error event if no record with the supplied key exists.
> >
> > Especially for .delete() this seems suboptimal as the author wanted
> > the entry with the given key removed anyway. A better alternative here
> > seems to be to "return" (through a success event) true or false to
> > indicate if a record was actually removed.
> >
> > For IDBObjectStore.get() it also seems like it will create an error
> > event in situations which aren't unexpected at all. For example
> > checking for the existence of certain information, or getting
> > information if it's there, but using some type of default if it's not.
> > An obvious choice here is to simply "return" (through a success event)
> > undefined if no entry is found. The downside with this is that you
> > can't tell the lack of an entry apart from an entry stored with the
> > value undefined.
> >
> > However it seemed more rare to want to tell those apart (you can
> > generally store something other than undefined), than to end up in
> > situations where you'd want to get() something which possibly didn't
> > exist. Additionally, you can still use openCursor() to tell the two
> > apart if really desired.
> >
> > I've for now checked in this change [1], but please speak up if you
> > think this is a bad idea for whatever reason.
>
> In general I'd disagree with you on get(), and point to basically all
> hash-table implementations which all give a way of telling whether you
> got a result or not, but the fact that javascript has false, null,
> *and* undefined makes me okay with this.  I believe it's sufficient to
> use 'undefined' as the flag for "there was nothing for this key in the
> objectstore", and just tell authors "don't put undefined in an
> objectstore; use false or null instead".
>
> ~TJ
>
>