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: Jonas Sicking <jonas@sicking.cc>
Date: Fri, 20 Jan 2012 14:30:36 -0800
Message-ID: <CA+c2ei8oyQ09XUJO7KyjVN9Cc6n2Oak18LoOicGwA54v7rYMEA@mail.gmail.com>
To: ben turner <bent.mozilla@gmail.com>
Cc: Israel Hilerio <israelh@microsoft.com>, Joshua Bell <jsbell@chromium.org>, Odin HÝrthe Omdal <odinho@opera.com>, Adam Herchenroether <aherchen@microsoft.com>, David Sheldon <dsheldon@microsoft.com>, "public-webapps@w3.org" <public-webapps@w3.org>
On Fri, Jan 20, 2012 at 12:23 PM, ben turner <bent.mozilla@gmail.com> wrote:
> Mozilla is fine with removing the special |keyPath:""| behavior.
> Please note that this will also mean that step 1 of the algorithm here
>
> †http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#dfn-steps-for-extracting-a-key-from-a-value-using-a-key-path
>
> will need to change.
>
> We do want to continue to allow set behavior without specifying the
> key twice, though, so we would propose adding an additional option to
> createObjectStore to accomplish this:
>
> †// Old way:
> †var set = db.createObjectStore("mySet", { keyPath:"" });
> †set.put(keyValue);
>
> †// New way:
> †var set = db.createObjectStore("mySet", { isSet: true });
> †set.put(keyValue);
>
> (We are not in love with "isSet", better names are highly encouraged!)
>
> What do you all think? This would allow us to continue to support nice
> set behavior without making the empty string "magic".

I actually think that the current behavior that we have is pretty
consistent. Any time you give the keyPath property a string we create
an objectStore with a keyPath. And any time you have an objectStore
with a keyPath you are not allowed to pass an explicit key since the
key is gotten from the keyPath. There's no special handling of empty
strings happening.

But I do agree that it can be somewhat confusing to tell
""/null/undefined apart since they are all falsy. In particular, an
expression like

if (myObjectStore.keyPath) {
  ...
}

doesn't work to test if an objectStore has a keyPath or not. You
instead need to check

if (myObjectStore.keyPath != null) {
  ...
}

or

if (typeof myObjectStore.keyPath == "string") {
  ...
}

Hence the "isSet" suggestion.

Though I also realized after talking to Ben that empty keyPaths show
up in indexes too. Consider creating a objectStore which maps peoples
names to email addresses. Then you can create an index when does the
opposite mapping, or which ensures that email addresses are unique:

var store = db.createObjectStore("people");
var index = store.createIndex("reverse", "", { unique: true });
store.add("john.doe@email.com", "John Doe");
store.add("mike@smith.org", "Mike Smith");

store.get("John Doe").onsuccess = function(e) {
  alert("John's email is " + e.target.result);
}
index.getKey("mike@smith.org").onsuccess = function(e) {
  alert("mike@smith.org is owned by " + e.target.result);
}

Are people proposing we remove empty keyPaths here too?

/ Jonas
Received on Friday, 20 January 2012 22:31:43 GMT

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