Re: [IndexedDB] Multientry with invalid keys

On Thu, Mar 1, 2012 at 8:20 PM, Jonas Sicking <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.