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: Mon, 8 Nov 2010 20:02:14 +0000
Message-ID: <AANLkTimUCnVaNjdw8pnSkk23jMkM-Kw4azE4-s8rUwFY@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Webapps WG <public-webapps@w3.org>

> I don't understand that.
> > with the proposal, undefined clearly means the entry does not exist as
> there is no way to put an undefined into the object store (as
> .put(undefined, key) deletes the entry).
> The confusing part is that a function called 'put' actually deletes
> something, especially since we also have a 'delete' function.

Sure, you could get rid of the delete function :-) I think the meaning of
"put(undefined, key)" is pretty clear.

> I would put the question this way: What problem are you trying to
> solve? If the problem is that people can't store "undefined" and then
> tell "undefined" apart from "not there" then your proposal doesn't
> solve that problem as "undefined" can't be stored at all.

Precisely, the solution I am proposing is based on disallowing storing of
'undefined'. What does it mean to store 'undefined' anyway? People can still
use null.

If you disallow storing 'undefined', "put(undefined, key)" would need to
throw an exception. I am proposing having "put(undefined, key)" be the same
as "remove(key)" to avoid having an exception. After all the initial concern
was avoiding having to handle exceptions.

Received on Monday, 8 November 2010 20:02:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:13 UTC