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

On Fri, Nov 12, 2010 at 12:59 AM, 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.

I'm not excited about the asymmetry either, but I think the
alternatives are worse.

> 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.

Works for me :) (This is excellent incentive to get editors to edit,
as long as we don't end up in edit wars :) )

/ Jonas

Received on Friday, 12 November 2010 19:06:27 UTC