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

On Wed, Jan 18, 2012 at 11:30 AM, Israel Hilerio <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.