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 <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.