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

Any updates on this thread?  Odin from Opera prefers the FailFast method we've been discussing. We're in the process of cleaning some issues and would like to get this resolved ASAP.  If we believe the current implementation in Firefox and Chrome is the way to go, I'm okay with it but I would like to know how we explain it to developers.



Thanks,



Israel


On Wednesday, January 18, 2012 3:55 PM, Israel Hilerio wrote:
Based on our retesting of Aurora and Canary, this is the behavior we're seeing:

When a null or undefined keyPath is provided to the createObjectStore API, you can add values to an Object Store as long as a key is specified during the execution of the Add API.  Not providing a key for the Add API will throw a DATA_ERR.

Providing an empty string keyPath to the createObjectStore produces the opposite behavior.  The Add API works as long as you don't provide any value for the key.  I'm assuming that the value is used as the key value and that is the reason why using an object as the value fails.

This difference in behavior seems strange to me.  I would expect the behavior to be the same between a keyPath value of empty string, null, and undefined.  How do you explain developers the reasons for the differences?  Is this the behavior we want to support moving forward?

Israel

On Wednesday, January 18, 2012 2:08 PM, Joshua Bell wrote:
On Wed, Jan 18, 2012 at 1:51 PM, ben turner <bent.mozilla@gmail.com<mailto:bent.mozilla@gmail.com>> wrote:
On Wed, Jan 18, 2012 at 1:40 PM, Israel Hilerio <israelh@microsoft.com<mailto:israelh@microsoft.com>> wrote:
> We tested on Firefox 8.0.1

Ah, ok. We made lots of big changes to key handling that will be in 11
I think. If you're curious I would recommend retesting with an aurora
build from https://www.mozilla.org/en-US/firefox/aurora.

Similarly, we've made lots of IDB-related fixes in Chrome 16 (stable), 17 (beta) and 18 (canary).