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 <israelh@microsoft.com<mailto:israelh@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 <jonas@sicking.cc<mailto:jonas@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.