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 <israelh@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.mozilla@gmail.com>
> wrote:****
>
> On Wed, Jan 18, 2012 at 1:40 PM, Israel Hilerio <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).****
>
> ** **
>