RE: [indexeddb] Do we need to support keyPaths with an empty string?

Joshua,

We did some testing in FF and Chrome and found different behaviors:

*        With keyPath: undefined or null.  In this scenario, FF and Chrome fails when executing add("foobar") without a key value.  However, Chrome allows you to add a valid key value or an object if you specify a key (i.e. add("foobar",1); ).  Firefox doesn't work in either case.  You end up with what appears to be a broken Object Store.

*        With keyPath: "" or empty string.  In this scenario, FF fails when executing add("foobar") without a key, but succeeds if you supply a key value.  It doesn't matter if the value being added is a valid key or an object.  Chrome succeeds when executing add("foobar") but fails when the value being added is an object (i.e. add({foo: "bar"}); ).  Chrome also fails when you specify a key value even if the value being added is a valid key value (i.e. add("foobar", 1); ).

Given the different behaviors, I wonder if the use case you described below (i.e. set scenario) is worth supporting.  Not supporting keyPath = undefined, null, and "" seem to provide a more consistent and clean story.  Returning an exception when a developer creates an Object Store with a keyPath of null, undefined, or empty string will provide a FailFast API.

What do you think?

Israel

On Wednesday, January 18, 2012 12:08 PM Joshua Bell wrote:
On Wed, Jan 18, 2012 at 11:30 AM, Israel Hilerio <israelh@microsoft.com<mailto:israelh@microsoft.com>> wrote:
On Friday, January 13, 2012 1:33 PM, Israel Hilerio wrote:
> Given the changes that Jonas made to the spec, on which other scenarios do we
> expect developers to specify a keyPath with an empty string (i.e. keyPath = "")?
> Do we still need to support this or can we just throw if this takes place.  I
> reopened bug #14985 [1] to reflect this.  Jonas or anyone else could you please
> clarify?
>
> Israel
> [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=14985
Any updates!  I expect this to apply to all of the following scenarios:
var obj = { keyPath : null };
var obj = { keyPath : undefined };
var obj = { keyPath : "" };

If I'm reading your concern right, the wording in the spec (and Jonas' comment in the bug) hints at the scenario of using the value as its own key for object stores as long as autoIncrement is false, e.g.

store = db.createObjectStore("my-store", {keyPath: ""});
store.put("abc"); // same as store.put("abc", "abc")
store.put([123]); // same as store.put([123], [123]);
store.put({foo: "bar"}); // keyPath yields value which is not a valid key, so should throw

Chrome supports this today (apart from a known bug with the error case).

One scenario would be using an object store to implement a Set, which seems like a valid use case if not particularly exciting.