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: Tue, 9 Nov 2010 00:04:34 +0000
Message-ID: <AANLkTimVJ8Nc_b4kqkHH6grMXCb999+Sq=oiqq2y50tA@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Webapps WG <public-webapps@w3.org>

> 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

> 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

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.

Received on Tuesday, 9 November 2010 00:05:10 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:28 UTC