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.
Cheers, Keean. On 8 November 2010 17:52, Tab Atkins Jr. <jackalm...@gmail.com> wrote: > On Mon, Nov 8, 2010 at 8:24 AM, Jonas Sicking <jo...@sicking.cc> wrote: > > Hi All, > > > > One of the things we discussed at TPAC was the fact that > > IDBObjectStore.get() and IDBObjectStore.delete() currently fire an > > error event if no record with the supplied key exists. > > > > Especially for .delete() this seems suboptimal as the author wanted > > the entry with the given key removed anyway. A better alternative here > > seems to be to "return" (through a success event) true or false to > > indicate if a record was actually removed. > > > > For IDBObjectStore.get() it also seems like it will create an error > > event in situations which aren't unexpected at all. For example > > checking for the existence of certain information, or getting > > information if it's there, but using some type of default if it's not. > > An obvious choice here is to simply "return" (through a success event) > > undefined if no entry is found. The downside with this is that you > > can't tell the lack of an entry apart from an entry stored with the > > value undefined. > > > > However it seemed more rare to want to tell those apart (you can > > generally store something other than undefined), than to end up in > > situations where you'd want to get() something which possibly didn't > > exist. Additionally, you can still use openCursor() to tell the two > > apart if really desired. > > > > I've for now checked in this change [1], but please speak up if you > > think this is a bad idea for whatever reason. > > In general I'd disagree with you on get(), and point to basically all > hash-table implementations which all give a way of telling whether you > got a result or not, but the fact that javascript has false, null, > *and* undefined makes me okay with this. I believe it's sufficient to > use 'undefined' as the flag for "there was nothing for this key in the > objectstore", and just tell authors "don't put undefined in an > objectstore; use false or null instead". > > ~TJ > >
