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

I really like this idea.  I only skimmed the arguments against it, but they
all seemed pretty hand-wavy to me.

J

On Mon, Nov 8, 2010 at 9:06 PM, Keean Schupke <keean@fry-it.com> wrote:

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