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

Yes, I prefer it due to the symmetry, and agree that its a judgment call. I
guess the advantage of allowing it is library's can disallow if they like.
The reverse is not true, if you disallow it a library cannot allow it.

On 12 Nov 2010 09:00, "Jeremy Orlow" <> wrote:
> On Fri, Nov 12, 2010 at 12:06 AM, Jonas Sicking <> wrote:
>> On Thu, Nov 11, 2010 at 11:44 AM, Jeremy Orlow <>
>> wrote:
>> > The email I responded to: "It would make sense if you make setting a
>> to
>> > undefined semantically equivalent to deleting the value (and no error
>> 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
> clearly technically superior solution and you have been doing most of the
> hard spec work lately.
> J

Received on Friday, 12 November 2010 10:02:34 UTC