FWIW, I have no objection to this change. On the other hand, if it's too late for some implementers to make this change I don't think it's critical to define a special case for it - it's useless but well defined behavior.

I assume we'd want to throw DataError?

Well, I guess "some implementors" mean IE. WebKit shouldn't have a problem with change, given how out of date that implementation is, Firefox is changing all the time, and in Opera we're also flexible.

I would like it to throw, but I can do without.


IE is currently (on my public preview build (probably super old)) throwing DataError on add() with keyPath [].

However, they seem to have *lots* of keyPath bugs in that version. "", [""], and even ["x", "y"] throw in add({x: 1, y: 2})!

I also see they have lots of other keyPath errors, like accepting "a*b" and "a/b" as keyPaths.

The reason i found this bug is that i stumbled upon code in Firefox whu h threw for this scenario, so we are certainly ok with keeping that behaviour :-)
But yes, feedback from Microsoft would be great.

"" and [""] *should* throw for { x: 1, y: 2 } by the way. The keyPath "" returns the value itself, and objects aren't valid keys

Yeah, that was not really what I was testing, I didn't have objects in there for other than [x, y]. Didn't read what I wrote too carefully because I changed the sentence quite a bit (from being too verbose).

I'm not really sure about the DataError though, -- that one is closer related to adding stuff to a store etc. Either SyntaxError or TypeError would fit a bit better though. Although maybe something else would be best.

Indeed, I think SyntaxError is a better exception. That way we throw SyntaxError for all sorts of malformed KeyPaths. I.e. all of

"ab c"
"foo.bar."
"x[0]"
[]

would throw SyntaxError exceptions.

Yeah, looks good. SyntaxError is what we're throwing since a week ago, so no-change if that is the resolution :P

Sounds good here too - just landed a patch to throw SyntaxError (well, DOMException.SYNTAX_ERR) for this in WebKit.

Today IE throws an InvalidAccessError if keyPath is an empty array. We have this behavior for empty string and array with empty string in the latest builds.
Array keyPaths are not supported.

Unfortunately, we won't be able to update our RTM build to support the proposed Exception type and will continue to support the current behavior you see in the Windows 8 Release Preview (stated above).

Ok, sounds like either way you won't be able to cover all edge cases (which I think is fine, bugs always exist) so it seems ok to me to specify that a SyntaxError should be thrown.

We rather not take this change.  Given that we are not going to be able to implement this change and that many web developers don't catch specific Exception types, we would rather keep the spec as is.  It seems it will provide better interoperability.

As things stand, you are even less compatible with the spec. Currently the spec says that you should *not* throw for empty-array keypaths.

So fixing this bug seems to lessen the difference between what IE is doing from "IE throws when it shouldn't" to "IE throws the wrong type of exception".

Got it! Let's go ahead with the proposed changes to the spec. We'll look into implementing these fixes when IE support array keypaths.

http://dvcs.w3.org/hg/IndexedDB/rev/908a6e3621d2

The change doesn't have any language forbidding using ['', 'length'] (or indeed [''] itself) as a keyPath.

That "would work" in a way when you give it a string, you'll get:

  "odin"   -> ["odin", 4]
  "joshua" -> ["joshua", 6]

But I read this as an empty string inside a keypath is not allowed either way.



This is how Opera and Firefox is behaving:

keypath          Opera   Firefox  spec     proposal
[]               throws  throws   throws   throws
['']             throws  throws   -        throws
['', '']         throws  -        -        throws
['', 'length']   throws  -        -        throws

So basically, I thought this bug, and I think the behaviour should be, if there's an empty string inside an array, throw SyntaxError.

The point of disallowing [] as a valid KeyPath is that it's completely useless to do so. Such a keypath can only ever generate one key value, namely []. So creating an index on [] is completely useless, and creating a objectStore with keyPath [] means that you can only store a single item, i.e. also pretty useless.

This doesn't apply to "", inside or outside of an array. I.e. you can definitely generate valid keys using a [""].

I can't however think of any usecases for using "" inside an Array though, but I'm not sure that we should be limiting edge cases that work just because we can't think of any uses. Should we similarly forbid using the same key in multiple places in the array?

In any case, this belongs in a different bug since it's not really related to empty arrays.