- From: Kris Zyp <kris@sitepen.com>
- Date: Mon, 08 Nov 2010 16:23:43 -0700
- To: Jonas Sicking <jonas@sicking.cc>
- CC: Webapps WG <public-webapps@w3.org>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 +1 from me. The purpose of undefined in JavaScript is to represent the value of a non-existent key, it fits perfectly with get() for a key that doesn't exist. This is exactly how property access works with JavaScript objects, so it is consistent and easy to understand for developers. Kris On 11/8/2010 9:24 AM, Jonas Sicking 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. > > [1] http://dvcs.w3.org/hg/IndexedDB/rev/aa86fe36c96e > > / Jonas > - -- Kris Zyp SitePen (503) 806-1841 http://sitepen.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzYhn4ACgkQ9VpNnHc4zAxFEACdEFskxkpFNw03sICteCHjMRgP +u8AnjfqH9fA6KHXmpMChvmAgl3kYrKG =gElN -----END PGP SIGNATURE-----
Received on Monday, 8 November 2010 23:25:14 UTC