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

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

Received on Monday, 8 November 2010 17:53:38 UTC