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.

Cheers,
Keean
On 12 Nov 2010 09:00, "Jeremy Orlow" <jorlow@chromium.org> wrote:
> 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