Jeremy, What you're saying about the discrepancies between empty string, null, and undefined make a lot of sense. That is one of the reasons for this proposal, to stop adding to the confusion. I also agree with you that we should support the "set" scenario and that this can be accomplished without having to support keypaths with empty strings, null, or undefined values.
I would like to hear from someone at Mozilla before we remove this from the spec. Thanks, Israel On Friday, January 20, 2012 10:48 AM, Joshua Bell wrote: rom: jsb...@google.com [mailto:jsb...@google.com] On Behalf Of Joshua Bell Sent: Friday, January 20, 2012 10:48 AM To: Israel Hilerio Cc: Odin Hørthe Omdal; Jonas Sicking (jo...@sicking.cc); ben turner (bent.mozi...@gmail.com); Adam Herchenroether; David Sheldon; public-webapps@w3.org Subject: Re: [indexeddb] Do we need to support keyPaths with an empty string? Empty strings, null, and undefined are all dangerous traps for the unwary in JavaScript already; all are falsy, some compare equal with ==, all ToString differently, some ToNumber differently. Personally, I try not to make any assumptions about how an API will respond to these inputs and approach with extreme caution. IMHO the "set" scenario is a valid use case, but that can be satisfied by specifying no key path and repeating the value during the put/add call, e.g. store.put(value, value). Therefore, I'm not opposed to removing empty string as a valid key path, but don't see it as particularly confusing, either. On Fri, Jan 20, 2012 at 9:58 AM, Israel Hilerio <isra...@microsoft.com<mailto:isra...@microsoft.com>> wrote: 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.mozi...@gmail.com<mailto:bent.mozi...@gmail.com>> wrote: On Wed, Jan 18, 2012 at 1:40 PM, Israel Hilerio <isra...@microsoft.com<mailto:isra...@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).
