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