W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2010

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

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 11 Nov 2010 13:06:12 -0800
Message-ID: <AANLkTin1B6fLjreAc4R7ud59mtJGKCndNGoqPG=bNisj@mail.gmail.com>
To: Jeremy Orlow <jorlow@chromium.org>
Cc: Keean Schupke <keean@fry-it.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, Webapps WG <public-webapps@w3.org>
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, 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.

/ Jonas
Received on Thursday, 11 November 2010 21:07:06 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:41 GMT