Re: [IndexedDB] Behavior of IDBObjectStore.get() and IDBObjectStore.delete() when record doesn't exist
On Fri, Nov 12, 2010 at 12:06 AM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Nov 11, 2010 at 11:44 AM, Jeremy Orlow jor...@chromium.org wrote: The email I responded to: 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. undefined should be symmetric. If something not existing returns undefined then passing in undefined should make it not exist. Overloading the meaning of a get returning undefined is ugly. And simply disallowing a value also seems a bit odd. But I think this is pretty elegant semantically. As I've asked previously in the tread. What problem are you trying to solve? Can you describe the type of application that gets easier to write/possible to write/has cleaner code/runs faster if we make this change? It seems like deleting on .put(undefined) creates a very unexpected behavior just to try to cover a rare edge case, wanting to both store undefined, This is not correct. The proposal was trying to remove an asymmetry within the API. and tell it apart from the lack of value.In fact, the proposal doesn't even solve that edge case since it no longer is possible to store undefined. Which brings me back to the question above of what problem you are trying to solve. ...this is trying to solve an asymmetry within the API. I know this is something I've gone back and forth on, but you'll remember that both Pablo and I (and maybe Andrei?) were not very excited about the asymmetry to begin with. Anyway, I'll differ to you since I think this (along with several other of the issues I've raised) are mostly judgement calls rather than issues with a clearly technically superior solution and you have been doing most of the hard spec work lately. J
Re: [IndexedDB] Behavior of IDBObjectStore.get() and IDBObjectStore.delete() when record doesn't exist
Yes, I prefer it due to the symmetry, and agree that its a judgment call. I guess the advantage of allowing it is library's can disallow if they like. The reverse is not true, if you disallow it a library cannot allow it. Cheers, Keean On 12 Nov 2010 09:00, Jeremy Orlow jor...@chromium.org wrote: On Fri, Nov 12, 2010 at 12:06 AM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Nov 11, 2010 at 11:44 AM, Jeremy Orlow jor...@chromium.org wrote: The email I responded to: 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. undefined should be symmetric. If something not existing returns undefined then passing in undefined should make it not exist. Overloading the meaning of a get returning undefined is ugly. And simply disallowing a value also seems a bit odd. But I think this is pretty elegant semantically. As I've asked previously in the tread. What problem are you trying to solve? Can you describe the type of application that gets easier to write/possible to write/has cleaner code/runs faster if we make this change? It seems like deleting on .put(undefined) creates a very unexpected behavior just to try to cover a rare edge case, wanting to both store undefined, This is not correct. The proposal was trying to remove an asymmetry within the API. and tell it apart from the lack of value.In fact, the proposal doesn't even solve that edge case since it no longer is possible to store undefined. Which brings me back to the question above of what problem you are trying to solve. ...this is trying to solve an asymmetry within the API. I know this is something I've gone back and forth on, but you'll remember that both Pablo and I (and maybe Andrei?) were not very excited about the asymmetry to begin with. Anyway, I'll differ to you since I think this (along with several other of the issues I've raised) are mostly judgement calls rather than issues with a clearly technically superior solution and you have been doing most of the hard spec work lately. J
Re: [IndexedDB] Behavior of IDBObjectStore.get() and IDBObjectStore.delete() when record doesn't exist
On Fri, Nov 12, 2010 at 12:59 AM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Nov 12, 2010 at 12:06 AM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Nov 11, 2010 at 11:44 AM, Jeremy Orlow jor...@chromium.org wrote: The email I responded to: 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. undefined should be symmetric. If something not existing returns undefined then passing in undefined should make it not exist. Overloading the meaning of a get returning undefined is ugly. And simply disallowing a value also seems a bit odd. But I think this is pretty elegant semantically. As I've asked previously in the tread. What problem are you trying to solve? Can you describe the type of application that gets easier to write/possible to write/has cleaner code/runs faster if we make this change? It seems like deleting on .put(undefined) creates a very unexpected behavior just to try to cover a rare edge case, wanting to both store undefined, This is not correct. The proposal was trying to remove an asymmetry within the API. and tell it apart from the lack of value.In fact, the proposal doesn't even solve that edge case since it no longer is possible to store undefined. Which brings me back to the question above of what problem you are trying to solve. ...this is trying to solve an asymmetry within the API. I know this is something I've gone back and forth on, but you'll remember that both Pablo and I (and maybe Andrei?) were not very excited about the asymmetry to begin with. I'm not excited about the asymmetry either, but I think the alternatives are worse. Anyway, I'll differ to you since I think this (along with several other of the issues I've raised) are mostly judgement calls rather than issues with a clearly technically superior solution and you have been doing most of the hard spec work lately. Works for me :) (This is excellent incentive to get editors to edit, as long as we don't end up in edit wars :) ) / Jonas
Re: [IndexedDB] Behavior of IDBObjectStore.get() and IDBObjectStore.delete() when record doesn't exist
I really like this idea. I only skimmed the arguments against it, but they all seemed pretty hand-wavy to me. J On Mon, Nov 8, 2010 at 9:06 PM, Keean Schupke ke...@fry-it.com wrote: 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
Re: [IndexedDB] Behavior of IDBObjectStore.get() and IDBObjectStore.delete() when record doesn't exist
On Thu, Nov 11, 2010 at 4:26 AM, Jeremy Orlow jor...@chromium.org wrote: I really like this idea. I only skimmed the arguments against it, but they all seemed pretty hand-wavy to me. Which idea specifically do you like? / Jonas
Re: [IndexedDB] Behavior of IDBObjectStore.get() and IDBObjectStore.delete() when record doesn't exist
The email I responded to: 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. undefined should be symmetric. If something not existing returns undefined then passing in undefined should make it not exist. Overloading the meaning of a get returning undefined is ugly. And simply disallowing a value also seems a bit odd. But I think this is pretty elegant semantically. J On Thu, Nov 11, 2010 at 7:04 PM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Nov 11, 2010 at 4:26 AM, Jeremy Orlow jor...@chromium.org wrote: I really like this idea. I only skimmed the arguments against it, but they all seemed pretty hand-wavy to me. Which idea specifically do you like? / Jonas
Re: [IndexedDB] Behavior of IDBObjectStore.get() and IDBObjectStore.delete() when record doesn't exist
On 11/11/2010 11:44 AM, Jeremy Orlow wrote: The email I responded to: 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. undefined should be symmetric. If something not existing returns undefined then passing in undefined should make it not exist. Overloading the meaning of a get returning undefined is ugly. And simply disallowing a value also seems a bit odd. But I think this is pretty elegant semantically. Sorry, but I disagree. I feel that calling put results in a deletion to be highly counter-intuitive, even if it makes sense when you think about it. Cheers, Shawn smime.p7s Description: S/MIME Cryptographic Signature
Re: [IndexedDB] Behavior of IDBObjectStore.get() and IDBObjectStore.delete() when record doesn't exist
On Thu, Nov 11, 2010 at 11:44 AM, Jeremy Orlow jor...@chromium.org wrote: The email I responded to: 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. undefined should be symmetric. If something not existing returns undefined then passing in undefined should make it not exist. Overloading the meaning of a get returning undefined is ugly. And simply disallowing a value also seems a bit odd. But I think this is pretty elegant semantically. As I've asked previously in the tread. What problem are you trying to solve? Can you describe the type of application that gets easier to write/possible to write/has cleaner code/runs faster if we make this change? It seems like deleting on .put(undefined) creates a very unexpected behavior just to try to cover a rare edge case, wanting to both store undefined, and tell it apart from the lack of value. In fact, the proposal doesn't even solve that edge case since it no longer is possible to store undefined. Which brings me back to the question above of what problem you are trying to solve. / Jonas
Re: [IndexedDB] Behavior of IDBObjectStore.get() and IDBObjectStore.delete() when record doesn't exist
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
Re: [IndexedDB] Behavior of IDBObjectStore.get() and IDBObjectStore.delete() when record doesn't exist
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
Re: [IndexedDB] Behavior of IDBObjectStore.get() and IDBObjectStore.delete() when record doesn't exist
On Mon, Nov 8, 2010 at 10:06 AM, Keean Schupke ke...@fry-it.com wrote: 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. I'm not sure I follow. There is no way to set a key on an existing entry in an object store. The closest thing would be IDBCursor.update(), but it specifically disallow changing the key at all. / Jonas
Re: [IndexedDB] Behavior of IDBObjectStore.get() and IDBObjectStore.delete() when record doesn't exist
Hi,
In code, if:
idbObjectStoreSync.put(key, undefined) does the same as
idbObjectStoreSync.remove(key)
then
idbObjectStoreSync.get(key) can safely return undefined for no such key
exists.
Consider:
idbObjectStoreSync.put('mykey', undefined); // deletes the object stored
under mykey or noop.
idbObjectStoreSync.get('mykey'); // returns 'undefined'
idbObjectStoreSync.put('mykey', myobject);
idbObjectStoreSync.get('mykey'); // returns 'myobject'
idbObjectStoreSync.put('mykey', undefined); // deletes the object stored
under mykey or noop.
idbObjectStoreSync.get('mykey'); // returns 'undefined'
Cheers,
Keean.
On 8 November 2010 18:27, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Nov 8, 2010 at 10:06 AM, Keean Schupke ke...@fry-it.com wrote:
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.
I'm not sure I follow. There is no way to set a key on an existing
entry in an object store. The closest thing would be
IDBCursor.update(), but it specifically disallow changing the key at
all.
/ Jonas
Re: [IndexedDB] Behavior of IDBObjectStore.get() and IDBObjectStore.delete() when record doesn't exist
Obviously I need to the key and value the correct way around for 'put'...
Cheers,
Keean.
On 8 November 2010 18:41, Keean Schupke ke...@fry-it.com wrote:
Hi,
In code, if:
idbObjectStoreSync.put(key, undefined) does the same as
idbObjectStoreSync.remove(key)
then
idbObjectStoreSync.get(key) can safely return undefined for no such key
exists.
Consider:
idbObjectStoreSync.put('mykey', undefined); // deletes the object stored
under mykey or noop.
idbObjectStoreSync.get('mykey'); // returns 'undefined'
idbObjectStoreSync.put('mykey', myobject);
idbObjectStoreSync.get('mykey'); // returns 'myobject'
idbObjectStoreSync.put('mykey', undefined); // deletes the object stored
under mykey or noop.
idbObjectStoreSync.get('mykey'); // returns 'undefined'
Cheers,
Keean.
On 8 November 2010 18:27, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Nov 8, 2010 at 10:06 AM, Keean Schupke ke...@fry-it.com wrote:
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.
I'm not sure I follow. There is no way to set a key on an existing
entry in an object store. The closest thing would be
IDBCursor.update(), but it specifically disallow changing the key at
all.
/ Jonas
Re: [IndexedDB] Behavior of IDBObjectStore.get() and IDBObjectStore.delete() when record doesn't exist
On Mon, Nov 8, 2010 at 10:41 AM, Keean Schupke ke...@fry-it.com wrote:
Hi,
In code, if:
idbObjectStoreSync.put(key, undefined) does the same as
idbObjectStoreSync.remove(key)
then
idbObjectStoreSync.get(key) can safely return undefined for no such key
exists.
Consider:
idbObjectStoreSync.put('mykey', undefined); // deletes the object stored
under mykey or noop.
idbObjectStoreSync.get('mykey'); // returns 'undefined'
idbObjectStoreSync.put('mykey', myobject);
idbObjectStoreSync.get('mykey'); // returns 'myobject'
idbObjectStoreSync.put('mykey', undefined); // deletes the object stored
under mykey or noop.
idbObjectStoreSync.get('mykey'); // returns 'undefined'
Indeed. But I think this is more unexpected and confusing than having
.get() return the same thing if the entry exists as if it contains
undefined.
/ Jonas
Re: [IndexedDB] Behavior of IDBObjectStore.get() and IDBObjectStore.delete() when record doesn't exist
Hi, Indeed. But I think this is more unexpected and confusing than having .get() return the same thing if the entry exists as if it contains undefined. / Jonas 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). Cheers, Keean.
Re: [IndexedDB] Behavior of IDBObjectStore.get() and IDBObjectStore.delete() when record doesn't exist
I was only suggesting this as it makes the operations symmetrical in the sense that if get returns undefined for key does not exist, put(undefined, key) should mean make this key not exist, in a declarative sense. For me this is clearer than the alternatives (which may require exceptions to deal with some cases). Of course its only a suggestion, and it nobody likes it, feel free to ignore it. Cheers, Keean. On 8 November 2010 18:57, Keean Schupke ke...@fry-it.com wrote: Hi, Indeed. But I think this is more unexpected and confusing than having .get() return the same thing if the entry exists as if it contains undefined. / Jonas 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). Cheers, Keean.
Re: [IndexedDB] Behavior of IDBObjectStore.get() and IDBObjectStore.delete() when record doesn't exist
On Monday, November 8, 2010, Keean Schupke ke...@fry-it.com wrote: Hi, Indeed. But I think this is more unexpected and confusing than having .get() return the same thing if the entry exists as if it contains undefined. / Jonas 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. 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. Additionally, as was mentioned, you can still tell undefined from not there by using a cursor. / Jonas
Re: [IndexedDB] Behavior of IDBObjectStore.get() and IDBObjectStore.delete() when record doesn't exist
Hi, 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. Cheers, Keean
Re: [IndexedDB] Behavior of IDBObjectStore.get() and IDBObjectStore.delete() when record doesn't exist
On Mon, Nov 8, 2010 at 12:02 PM, Keean Schupke ke...@fry-it.com wrote:
Hi,
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 guess we'll have to agree to disagree on that one :)
My concern with something like this is that we'll see code do stuff like:
function myStoreFunction(objectStoreName, key, value) {
os = db.transaction([objectStoreName]).objectStore(objectStoreName);
if (value === undefined) {
os.put(null, key);
}
else {
os.put(value, key);
}
}
which does not seem like a net win for anyone.
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.
Wait, your solution doesn't solve the above described problem. The
described problem was
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.
Your solution doesn't solve that problem.
/ Jonas
Re: [IndexedDB] Behavior of IDBObjectStore.get() and IDBObjectStore.delete() when record doesn't exist
What is the use case for storing undefined in an object-store?
Cheers,
Keean.
On 8 November 2010 20:59, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Nov 8, 2010 at 12:02 PM, Keean Schupke ke...@fry-it.com wrote:
Hi,
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 guess we'll have to agree to disagree on that one :)
My concern with something like this is that we'll see code do stuff like:
function myStoreFunction(objectStoreName, key, value) {
os = db.transaction([objectStoreName]).objectStore(objectStoreName);
if (value === undefined) {
os.put(null, key);
}
else {
os.put(value, key);
}
}
which does not seem like a net win for anyone.
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.
Wait, your solution doesn't solve the above described problem. The
described problem was
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.
Your solution doesn't solve that problem.
/ Jonas
Re: [IndexedDB] Behavior of IDBObjectStore.get() and IDBObjectStore.delete() when record doesn't exist
Let me put it another way. Why do you want to allow putting 'undefined' into the object store? All that does is make the API for get ambiguous. What does it gain you? Why do you want to make 'get' ambiguous? I think having an unambiguous API for 'get' is worth more than being able to 'put' 'undefined' values into the object store. Cheers, Keean. On 8 November 2010 23:10, Jonas Sicking jo...@sicking.cc wrote: On Mon, Nov 8, 2010 at 2:39 PM, Keean Schupke ke...@fry-it.com wrote: The problem I am trying to solve is not knowing if get(key) === undefined means the key does not exist or there is a key with a value of undefined. The solution is to disallow inserting undefined. Now there is no ambiguity, if get(key) returns undefined, it _must_ be because the key does not exist. Does this make sense so far? But if saying you're not allowed to insert undefined as value is an acceptable solution, why isn't you can't tell them apart using get() an acceptable solution? What use case does the first solution cater to that isn't solved by the second solution? / Jonas
Re: [IndexedDB] Behavior of IDBObjectStore.get() and IDBObjectStore.delete() when record doesn't exist
-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-
Re: [IndexedDB] Behavior of IDBObjectStore.get() and IDBObjectStore.delete() when record doesn't exist
On Mon, Nov 8, 2010 at 3:18 PM, Keean Schupke ke...@fry-it.com wrote: Let me put it another way. Why do you want to allow putting 'undefined' into the object store? All that does is make the API for get ambiguous. What does it gain you? Why do you want to make 'get' ambiguous? It seems like a loose-loose situation to prevent it. Implementors will have to add code to check for 'undefined' all the time, and users of the API can't store 'undefined' if they would like to. I think having an unambiguous API for 'get' is worth more than being able to 'put' 'undefined' values into the object store. Can you describe the application that would be easier to write, possible to write, faster to run or have cleaner code if we forbade putting 'undefined' in an object store? / Jonas
Re: [IndexedDB] Behavior of IDBObjectStore.get() and IDBObjectStore.delete() when record doesn't exist
If more than one developer are working on a project, there is no way I can
know if the other developer has put 'undefined' objects into the store
(unless the specification enforces it).
So every time I am checking if a key exists (maybe to delete the key) I need
to check if it _really_ exists, or else I can run into problems. For
example:
In module A:
put(undefined, key);
In module B:
if (get(key) !== undefined) {
remove(key);
}
So the object store will fill up with key = undefined until we run out of
memory.
Cheers,
Keean.
On 8 November 2010 23:24, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Nov 8, 2010 at 3:18 PM, Keean Schupke ke...@fry-it.com wrote:
Let me put it another way. Why do you want to allow putting 'undefined'
into
the object store? All that does is make the API for get ambiguous. What
does
it gain you? Why do you want to make 'get' ambiguous?
It seems like a loose-loose situation to prevent it. Implementors will
have to add code to check for 'undefined' all the time, and users of
the API can't store 'undefined' if they would like to.
I think having an unambiguous API for 'get' is worth more than being able
to
'put' 'undefined' values into the object store.
Can you describe the application that would be easier to write,
possible to write, faster to run or have cleaner code if we forbade
putting 'undefined' in an object store?
/ Jonas
Re: [IndexedDB] Behavior of IDBObjectStore.get() and IDBObjectStore.delete() when record doesn't exist
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
If you are looking for ways to shoot yourself in the foot, why not
just do:
undefined = true;
Storing undefined is not an important use case, practical usage is far
more important than optimizing for edge cases just because you can
think of them.
Kris
On 11/8/2010 4:33 PM, Keean Schupke wrote:
If more than one developer are working on a project, there is no
way I can know if the other developer has put 'undefined' objects
into the store (unless the specification enforces it).
So every time I am checking if a key exists (maybe to delete the
key) I need to check if it _really_ exists, or else I can run into
problems. For example:
In module A: put(undefined, key);
In module B: if (get(key) !== undefined) { remove(key); }
So the object store will fill up with key = undefined until we
run out of memory.
Cheers, Keean.
On 8 November 2010 23:24, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Nov 8, 2010 at 3:18 PM, Keean Schupke ke...@fry-it.com
mailto:ke...@fry-it.com wrote:
Let me put it another way. Why do you want to allow putting
'undefined' into
the object store? All that does is make the API for get
ambiguous. What does
it gain you? Why do you want to make 'get' ambiguous?
It seems like a loose-loose situation to prevent it. Implementors
will have to add code to check for 'undefined' all the time, and
users of the API can't store 'undefined' if they would like to.
I think having an unambiguous API for 'get' is worth more than
being able to
'put' 'undefined' values into the object store.
Can you describe the application that would be easier to write,
possible to write, faster to run or have cleaner code if we
forbade putting 'undefined' in an object store?
/ 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/
iEYEARECAAYFAkzYioUACgkQ9VpNnHc4zAxceQCeI7SF6MWWHDikmbtFECy4wKBd
pWMAoKThBuiaXg0V1rM7nYh0abp6t7SU
=2FSo
-END PGP SIGNATURE-
Re: [IndexedDB] Behavior of IDBObjectStore.get() and IDBObjectStore.delete() when record doesn't exist
On Mon, Nov 8, 2010 at 3:33 PM, Keean Schupke ke...@fry-it.com wrote:
If more than one developer are working on a project, there is no way I can
know if the other developer has put 'undefined' objects into the store
(unless the specification enforces it).
So every time I am checking if a key exists (maybe to delete the key) I need
to check if it _really_ exists, or else I can run into problems. For
example:
In module A:
put(undefined, key);
In module B:
if (get(key) !== undefined) {
remove(key);
}
So the object store will fill up with key = undefined until we run out of
memory.
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?
Don't you need to coordinate with other developers to know what any
other value returned from get() means?
Do you have the same problem with foo.bar as outlined in my previous
email? If not, why not?
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.
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.
/ Jonas
Re: [IndexedDB] Behavior of IDBObjectStore.get() and IDBObjectStore.delete() when record doesn't exist
On Mon, Nov 8, 2010 at 4:04 PM, Keean Schupke ke...@fry-it.com wrote:
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...
That is no longer the case, see the first email in this thread :)
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.
A spec can never cover 100% of all use cases. Often covering the last
10-20% of the use cases adds as much complexity or API surface, if not
more, as covering the first 80-90%. The trick really is to know when
to stop.
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.
Note that you can easily do this using openCursor already. In the
synchronous API you could easily implement exists by doing:
IDBObjectStoreSync.prototype.exists = function(key) {
return this.openCursor(key) !== undefined;
}
I think we should keep exists() in mind for v2 of the interface. It
has other benefits over get() and openCursor() in that if the stored
value is very big it doesn't require time to deserialize it out of the
database. But given how close we are to finishing v1 I'd rather not
add it now. I have added it to my stuff we should reexamine in v2
list though.
/ Jonas
Re: [IndexedDB] Behavior of IDBObjectStore.get() and IDBObjectStore.delete() when record doesn't exist
Sounds good to me...
Cheers,
Keean.
On 9 November 2010 00:16, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Nov 8, 2010 at 4:04 PM, Keean Schupke ke...@fry-it.com wrote:
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...
That is no longer the case, see the first email in this thread :)
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.
A spec can never cover 100% of all use cases. Often covering the last
10-20% of the use cases adds as much complexity or API surface, if not
more, as covering the first 80-90%. The trick really is to know when
to stop.
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.
Note that you can easily do this using openCursor already. In the
synchronous API you could easily implement exists by doing:
IDBObjectStoreSync.prototype.exists = function(key) {
return this.openCursor(key) !== undefined;
}
I think we should keep exists() in mind for v2 of the interface. It
has other benefits over get() and openCursor() in that if the stored
value is very big it doesn't require time to deserialize it out of the
database. But given how close we are to finishing v1 I'd rather not
add it now. I have added it to my stuff we should reexamine in v2
list though.
/ Jonas
Re: [IndexedDB] Behavior of IDBObjectStore.get() and IDBObjectStore.delete() when record doesn't exist
On Mon, Nov 8, 2010 at 4:16 PM, Jonas Sicking jo...@sicking.cc wrote: 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. A spec can never cover 100% of all use cases. Often covering the last 10-20% of the use cases adds as much complexity or API surface, if not more, as covering the first 80-90%. The trick really is to know when to stop. Oh, I should be more clear. The spec definitely needs to *define* all edge cases though. In general the spec currently tries to very precisely define behavior in all edge cases, including this one. I also added a note pointing out this very edge case as well as suggest using openCursor as a workaround. If you do find other cases which are not explicitly defined, please do file bugs or send emails to this list. / Jonas
