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: Keean Schupke <keean@fry-it.com>
Date: Mon, 8 Nov 2010 23:18:52 +0000
Message-ID: <AANLkTi=DNuhXY3mNQJUt0_U_s3ASj7_ujBrtmHWxuV43@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Webapps WG <public-webapps@w3.org>
Let me put it another way. Why do you want to allow putting 'undefined' into
the object store? All that does is make the API for get ambiguous. What does
it gain you? Why do you want to make 'get' ambiguous?

I think having an unambiguous API for 'get' is worth more than being able to
'put' 'undefined' values into the object store.


On 8 November 2010 23:10, Jonas Sicking <jonas@sicking.cc> wrote:

> On Mon, Nov 8, 2010 at 2:39 PM, Keean Schupke <keean@fry-it.com> wrote:
> > The problem I am trying to solve is not knowing if "get(key) ===
> undefined"
> > means the key does not exist or there is a key with a value of undefined.
> > The solution is to disallow inserting undefined. Now there is no
> ambiguity,
> > if get(key) returns undefined, it _must_ be because the key does not
> exist.
> > Does this make sense so far?
> But if saying "you're not allowed to insert undefined as value" is an
> acceptable solution, why isn't "you can't tell them apart using get()" an
> acceptable solution?
> What use case does the first solution cater to that isn't solved by
> the second solution?
> / Jonas
Received on Monday, 8 November 2010 23:19:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:13 UTC