Re: [IndexedDB] Multientry with invalid keys
This should now be fixed in editor drafts. On Sat, Mar 3, 2012 at 2:58 AM, Jonas Sicking jo...@sicking.cc wrote: Oh, I missed Joshua's last email. So it seems everyone is in agreement. I'll make the edits and then close the bug. / Jonas On Saturday, March 3, 2012, Jonas Sicking wrote: Crap, we need to better about filing bugs :-) Yes, my understanding is that there was agreement to update the spec such that if evaluating and index's keyPath does not yield a valid key that does not affect weather the value is inserted in the objectStore. In other words, indexes do not add constraints other than when explicitly called out using the 'unique' feature. My logic was that it would be consistent with this behaviour to ignore any invalid keys in a multiEntry index rather than to throw the whole thing out. If people are on with this ill edit this into the spec over the weekend. / Jonas On Saturday, March 3, 2012, Israel Hilerio wrote: I’ve created a bug to track this issue: https://www.w3.org/Bugs/Public/show_bug.cgi?id=16211 Israel On Friday, March 02, 2012 4:39 PM, Odin Hørthe Omdal wrote: From: Israel Hilerio isra...@microsoft.com Unfortunately, we didn’t update the spec to reflect this agreement. You or I could open a bug to ensure the spec is updated to capture this change. Yes, better get it into the spec :-) About the behavior itself, FWIW, I think it's a reasonable one. -- Odin, Opera
Re: [IndexedDB] Multientry with invalid keys
On Thu, Mar 1, 2012 at 8:20 PM, Jonas Sicking jo...@sicking.cc wrote:
Hi All,
What should we do for the following scenario:
store = db.createObjectStore(store);
index = store.createIndex(index, x, { multiEntry: true });
store.add({ x: [a, b, {}, c] }, 1);
index.count().onsuccess = function(event) {
alert(event.target.result);
}
It's clear that the add should be successful since indexes never add
constraints other than through the explicit 'unique' option. But what
is stored in the index? I.e. what should a multiEntry index do if one
of the items in the array is not a valid key?
Note that this is different from if we had not had a multiEntry index
since in that case the whole array is used as a key and it would
clearly not constitute a valid key. Thus if it was not a multiEntry
index 0 entries would be added to the index.
But for multiEntry indexes we can clearly choose to either reject the
entry completely and not store anything in the index if any of the
elements in the array is not a valid key. Or we could simply skip any
elements that aren't valid keys but insert the other ones.
In other words, 0 or 3 would be possible valid answers to what is
alerted by the script above.
Currently in Firefox we alert 3. In other words we don't reject the
whole array for multiEntry indexes, just the elements that are invalid
keys.
/ Jonas
Currently, Chromium follows the current letter of the spec and treats the
two cases as the same: If there are any indexes referencing this object
store whose key path is a string, evaluating their key path on
the value parameter yields a value, and that value is not a valid key. an
error is thrown. The multiEntry flag is ignored during this validation
during the call. So Chromium would alert 0.
I agree it could go either way. My feeling is that the spec overall tends
to be strict about the inputs; as we've added more validation to the
Chromium implementation we've surprised some users who were getting away
with sloppy data, but they're understanding and IMHO it's better to be
strict here if we're strict everywhere else, so non-indexable items
generate errors rather than being silently ignored.
RE: [IndexedDB] Multientry with invalid keys
We agree with FF's implementation. It seems to match the current sparse index
concept where values that can't be indexed are automatically ignored. However,
this doesn't prevent them from being added.
Israel
On Friday, March 02, 2012 8:59 AM, Joshua Bell wrote:
On Thu, Mar 1, 2012 at 8:20 PM, Jonas Sicking
jo...@sicking.ccmailto:jo...@sicking.cc wrote:
Hi All,
What should we do for the following scenario:
store = db.createObjectStore(store);
index = store.createIndex(index, x, { multiEntry: true });
store.add({ x: [a, b, {}, c] }, 1);
index.count().onsuccess = function(event) {
alert(event.target.result);
}
It's clear that the add should be successful since indexes never add
constraints other than through the explicit 'unique' option. But what
is stored in the index? I.e. what should a multiEntry index do if one
of the items in the array is not a valid key?
Note that this is different from if we had not had a multiEntry index
since in that case the whole array is used as a key and it would
clearly not constitute a valid key. Thus if it was not a multiEntry
index 0 entries would be added to the index.
But for multiEntry indexes we can clearly choose to either reject the
entry completely and not store anything in the index if any of the
elements in the array is not a valid key. Or we could simply skip any
elements that aren't valid keys but insert the other ones.
In other words, 0 or 3 would be possible valid answers to what is
alerted by the script above.
Currently in Firefox we alert 3. In other words we don't reject the
whole array for multiEntry indexes, just the elements that are invalid
keys.
/ Jonas
Currently, Chromium follows the current letter of the spec and treats the two
cases as the same: If there are any indexes referencing this object store
whose key path is a string, evaluating their key path on the value parameter
yields a value, and that value is not a valid key. an error is thrown. The
multiEntry flag is ignored during this validation during the call. So Chromium
would alert 0.
I agree it could go either way. My feeling is that the spec overall tends to be
strict about the inputs; as we've added more validation to the Chromium
implementation we've surprised some users who were getting away with sloppy
data, but they're understanding and IMHO it's better to be strict here if
we're strict everywhere else, so non-indexable items generate errors rather
than being silently ignored.
Re: [IndexedDB] Multientry with invalid keys
I should clarify; Chromium will not actually alert 0, but would raise an
exception (unless caught, of course)
Israel's comment makes me wonder if there's some disagreement or confusion
about this clause of the spec:
If there are any indexes referencing this object store whose key path is a
string, evaluating their key path on the value parameter yields a value,
and that value is not a valid key.
store = db.createObjectStore(store);
index = store.createIndex(index, x)
store.put({}, 1);
store.put({ x: null }, 2);
index.count().onsuccess = function(event) { alert(event.target.result); }
I would expect the first put() to succeed, the second put() to raise an
exception. Is there any disagreement about this? I can see the statement
... where values that can't be indexed are automatically ignored being
interpreted as the second put() should also succeed, alerting 0. But again,
that doesn't seem to match the spec.
On Fri, Mar 2, 2012 at 11:52 AM, Israel Hilerio isra...@microsoft.comwrote:
We agree with FF’s implementation. It seems to match the current sparse
index concept where values that can’t be indexed are automatically
ignored. However, this doesn’t prevent them from being added.
** **
Israel
** **
On Friday, March 02, 2012 8:59 AM, Joshua Bell wrote:
On Thu, Mar 1, 2012 at 8:20 PM, Jonas Sicking jo...@sicking.cc wrote:***
*
Hi All,
What should we do for the following scenario:
store = db.createObjectStore(store);
index = store.createIndex(index, x, { multiEntry: true });
store.add({ x: [a, b, {}, c] }, 1);
index.count().onsuccess = function(event) {
alert(event.target.result);
}
It's clear that the add should be successful since indexes never add
constraints other than through the explicit 'unique' option. But what
is stored in the index? I.e. what should a multiEntry index do if one
of the items in the array is not a valid key?
Note that this is different from if we had not had a multiEntry index
since in that case the whole array is used as a key and it would
clearly not constitute a valid key. Thus if it was not a multiEntry
index 0 entries would be added to the index.
But for multiEntry indexes we can clearly choose to either reject the
entry completely and not store anything in the index if any of the
elements in the array is not a valid key. Or we could simply skip any
elements that aren't valid keys but insert the other ones.
In other words, 0 or 3 would be possible valid answers to what is
alerted by the script above.
Currently in Firefox we alert 3. In other words we don't reject the
whole array for multiEntry indexes, just the elements that are invalid
keys.
/ Jonas
** **
Currently, Chromium follows the current letter of the spec and treats the
two cases as the same: If there are any indexes referencing this object
store whose key path is a string, evaluating their key path on
the value parameter yields a value, and that value is not a valid key. an
error is thrown. The multiEntry flag is ignored during this validation
during the call. So Chromium would alert 0.
** **
I agree it could go either way. My feeling is that the spec overall tends
to be strict about the inputs; as we've added more validation to the
Chromium implementation we've surprised some users who were getting away
with sloppy data, but they're understanding and IMHO it's better to be
strict here if we're strict everywhere else, so non-indexable items
generate errors rather than being silently ignored.
** **
RE: [IndexedDB] Multientry with invalid keys
I think I know where the misunderstanding is coming from. There was an email
thread [1] in which Jonas proposed this change and we had agreed to the
following:
I propose that we remove the requirement that we have today that if
an indexed property exists, it has to contain a valid value. Instead,
if a property doesn't contain a valid key value, we simply don't add an
entry to the index.
This would of course apply both when inserting data into a
objectStore which already has indexes, as well as when creating
indexes for an object store which already contains data.
Unfortunately, we didn't update the spec to reflect this agreement. You or I
could open a bug to ensure the spec is updated to capture this change. Let me
know,
Israel
[1] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0534.html
On Friday, March 02, 2012 12:11 PM, Joshua Bell wrote:
I should clarify; Chromium will not actually alert 0, but would raise an
exception (unless caught, of course)
Israel's comment makes me wonder if there's some disagreement or confusion
about this clause of the spec:
If there are any indexes referencing this object store whose key path is a
string, evaluating their key path on the value parameter yields a value, and
that value is not a valid key.
store = db.createObjectStore(store);
index = store.createIndex(index, x)
store.put({}, 1);
store.put({ x: null }, 2);
index.count().onsuccess = function(event) { alert(event.target.result); }
I would expect the first put() to succeed, the second put() to raise an
exception. Is there any disagreement about this? I can see the statement ...
where values that can't be indexed are automatically ignored being interpreted
as the second put() should also succeed, alerting 0. But again, that doesn't
seem to match the spec.
On Fri, Mar 2, 2012 at 11:52 AM, Israel Hilerio
isra...@microsoft.commailto:isra...@microsoft.com wrote:
We agree with FF's implementation. It seems to match the current sparse index
concept where values that can't be indexed are automatically ignored. However,
this doesn't prevent them from being added.
Israel
On Friday, March 02, 2012 8:59 AM, Joshua Bell wrote:
On Thu, Mar 1, 2012 at 8:20 PM, Jonas Sicking
jo...@sicking.ccmailto:jo...@sicking.cc wrote:
Hi All,
What should we do for the following scenario:
store = db.createObjectStore(store);
index = store.createIndex(index, x, { multiEntry: true });
store.add({ x: [a, b, {}, c] }, 1);
index.count().onsuccess = function(event) {
alert(event.target.result);
}
It's clear that the add should be successful since indexes never add
constraints other than through the explicit 'unique' option. But what
is stored in the index? I.e. what should a multiEntry index do if one
of the items in the array is not a valid key?
Note that this is different from if we had not had a multiEntry index
since in that case the whole array is used as a key and it would
clearly not constitute a valid key. Thus if it was not a multiEntry
index 0 entries would be added to the index.
But for multiEntry indexes we can clearly choose to either reject the
entry completely and not store anything in the index if any of the
elements in the array is not a valid key. Or we could simply skip any
elements that aren't valid keys but insert the other ones.
In other words, 0 or 3 would be possible valid answers to what is
alerted by the script above.
Currently in Firefox we alert 3. In other words we don't reject the
whole array for multiEntry indexes, just the elements that are invalid
keys.
/ Jonas
Currently, Chromium follows the current letter of the spec and treats the two
cases as the same: If there are any indexes referencing this object store
whose key path is a string, evaluating their key path on the value parameter
yields a value, and that value is not a valid key. an error is thrown. The
multiEntry flag is ignored during this validation during the call. So Chromium
would alert 0.
I agree it could go either way. My feeling is that the spec overall tends to be
strict about the inputs; as we've added more validation to the Chromium
implementation we've surprised some users who were getting away with sloppy
data, but they're understanding and IMHO it's better to be strict here if
we're strict everywhere else, so non-indexable items generate errors rather
than being silently ignored.
Re: RE: [IndexedDB] Multientry with invalid keys
From: Israel Hilerio isra...@microsoft.com Unfortunately, we didn’t update the spec to reflect this agreement. You or I could open a bug to ensure the spec is updated to capture this change. Yes, better get it into the spec :-) About the behavior itself, FWIW, I think it's a reasonable one. -- Odin, Opera
RE: [IndexedDB] Multientry with invalid keys
I’ve created a bug to track this issue: https://www.w3.org/Bugs/Public/show_bug.cgi?id=16211 Israel On Friday, March 02, 2012 4:39 PM, Odin Hørthe Omdal wrote: From: Israel Hilerio isra...@microsoft.commailto:isra...@microsoft.com Unfortunately, we didn’t update the spec to reflect this agreement. You or I could open a bug to ensure the spec is updated to capture this change. Yes, better get it into the spec :-) About the behavior itself, FWIW, I think it's a reasonable one. -- Odin, Opera
Re: [IndexedDB] Multientry with invalid keys
Thanks. Based on this, I agree that in the multiEntry scenario at the start of this thread, 3 is the more consistent result. On Fri, Mar 2, 2012 at 5:29 PM, Israel Hilerio isra...@microsoft.comwrote: I’ve created a bug to track this issue: https://www.w3.org/Bugs/Public/show_bug.cgi?id=16211 ** ** Israel ** ** On Friday, March 02, 2012 4:39 PM, Odin Hørthe Omdal wrote: From: Israel Hilerio isra...@microsoft.com Unfortunately, we didn’t update the spec to reflect this agreement. You or I could open a bug to ensure the spec is updated to capture this change. ** ** Yes, better get it into the spec :-) ** ** About the behavior itself, FWIW, I think it's a reasonable one. ** ** -- Odin, Opera
Re: [IndexedDB] Multientry with invalid keys
Crap, we need to better about filing bugs :-)
Yes, my understanding is that there was agreement to update the spec such
that if evaluating and index's keyPath does not yield a valid key that does
not affect weather the value is inserted in the objectStore.
In other words, indexes do not add constraints other than when explicitly
called out using the 'unique' feature.
My logic was that it would be consistent with this behaviour to ignore any
invalid keys in a multiEntry index rather than to throw the whole thing out.
If people are on with this ill edit this into the spec over the weekend.
/ Jonas
On Saturday, March 3, 2012, Israel Hilerio wrote:
I’ve created a bug to track this issue:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16211
** **
Israel
** **
On Friday, March 02, 2012 4:39 PM, Odin Hørthe Omdal wrote:
From: Israel Hilerio isra...@microsoft.com javascript:_e({}, 'cvml',
'isra...@microsoft.com');
Unfortunately, we didn’t update the spec to reflect this agreement.
You or I could open a bug to ensure the spec is updated to capture
this change.
** **
Yes, better get it into the spec :-)
** **
About the behavior itself, FWIW, I think it's a reasonable one.
** **
--
Odin, Opera
Re: [IndexedDB] Multientry with invalid keys
Oh, I missed Joshua's last email. So it seems everyone is in agreement. I'll make the edits and then close the bug. / Jonas On Saturday, March 3, 2012, Jonas Sicking wrote: Crap, we need to better about filing bugs :-) Yes, my understanding is that there was agreement to update the spec such that if evaluating and index's keyPath does not yield a valid key that does not affect weather the value is inserted in the objectStore. In other words, indexes do not add constraints other than when explicitly called out using the 'unique' feature. My logic was that it would be consistent with this behaviour to ignore any invalid keys in a multiEntry index rather than to throw the whole thing out. If people are on with this ill edit this into the spec over the weekend. / Jonas On Saturday, March 3, 2012, Israel Hilerio wrote: I’ve created a bug to track this issue: https://www.w3.org/Bugs/Public/show_bug.cgi?id=16211 ** ** Israel ** ** On Friday, March 02, 2012 4:39 PM, Odin Hørthe Omdal wrote: From: Israel Hilerio isra...@microsoft.com Unfortunately, we didn’t update the spec to reflect this agreement. You or I could open a bug to ensure the spec is updated to capture this change. ** ** Yes, better get it into the spec :-) ** ** About the behavior itself, FWIW, I think it's a reasonable one. ** ** -- Odin, Opera
