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

Hi,


> Why do you want to check that a key exists before you delete it? Why
> not just call delete(key) always and rest assured that it's gone?
>
>
because it will throw an exception if the key does not exist...


> Don't you need to coordinate with other developers to know what any
> other value returned from get() means?


 fair point... although it would be better if this was obvious from the
spec.


>
> Do you have the same problem with foo.bar as outlined in my previous
> email? If not, why not?
>

did I miss that email? not sure what this is about.


>
> For what it's worth, I do agree that it isn't ideal that .get() can't
> tell the two apart. However I think that forbidding storing undefined
> is a worse solution which just moves the problem from one place to
> another. Consider code that does:
>
> for (i = 0; i < myArray.length; ++i) {
>  objectStore.put(myArray[i]);
> }
>
> and then creating a cursor which iterates over all stored values. This
> code would be buggy since it doesn't deal with 'undefined' being
> stored in the array.
>

This is the best argument against this so far...


>
> Similar to Kris, I think worrying about 'undefined' is worrying about
> an edge case. Simplicity is better than trying to cove every possible
> edge case.


I thought edge cases are precisely what a specification is supposed to deal
with.


Anyway, although I don't agree with the other reasons, I find the array case
compelling. So lets ignore the proposal to disallow storing undefined.

Perhaps you could add a boolean method "exists(key)" to IDBObjectStore to
make it easier to tell the two apart.


Cheers,
Keean.