W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2012

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

From: Joshua Bell <jsbell@chromium.org>
Date: Wed, 18 Jan 2012 12:07:37 -0800
Message-ID: <CAD649j7Zhb=Hr5misVdjMgKhRjpZgLSPtZ4gfP4ho5Femr=QSA@mail.gmail.com>
To: "public-webapps@w3.org" <public-webapps@w3.org>, David Sheldon <dsheldon@microsoft.com>, Adam Herchenroether <aherchen@microsoft.com>, Israel Hilerio <israelh@microsoft.com>
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.
Received on Wednesday, 18 January 2012 20:08:13 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:50 GMT