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

On Fri, Nov 12, 2010 at 12:06 AM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Thu, Nov 11, 2010 at 11:44 AM, Jeremy Orlow <jorlow@chromium.org>
> wrote:
> > The email I responded to: "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."
> > undefined should be symmetric.  If something not existing returns
> undefined
> > then passing in undefined should make it not exist.  Overloading the
> meaning
> > of a get returning undefined is ugly.  And simply disallowing a value
> also
> > seems a bit odd.  But I think this is pretty elegant semantically.
>
> As I've asked previously in the tread. What problem are you trying to
> solve? Can you describe the type of application that gets easier to
> write/possible to write/has cleaner code/runs faster if we make this
> change?
>
> It seems like deleting on .put(undefined) creates a very unexpected
> behavior just to try to cover a rare edge case, wanting to both store
> undefined,


This is not correct.  The proposal was trying to remove an asymmetry within
the API.


> and tell it apart from the lack of value.In fact, the
> proposal doesn't even solve that edge case since it no longer is
> possible to store undefined. Which brings me back to the question
> above of what problem you are trying to solve.
>

...this is trying to solve an asymmetry within the API.

I know this is something I've gone back and forth on, but you'll remember
that both Pablo and I (and maybe Andrei?) were not very excited about
the asymmetry to begin with.

Anyway, I'll differ to you since I think this (along with several other of
the issues I've raised) are mostly judgement calls rather than issues with a
clearly technically superior solution and you have been doing most of the
hard spec work lately.

J