This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 17657 - Empty arrays shouldn't be valid KeyPaths
Summary: Empty arrays shouldn't be valid KeyPaths
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: Indexed Database API (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: This bug has no owner yet - up for the taking
QA Contact: public-webapps-bugzilla
Depends on:
Reported: 2012-06-30 03:20 UTC by Jonas Sicking (Not reading bugmail)
Modified: 2012-09-22 01:49 UTC (History)
5 users (show)

See Also:


Description Jonas Sicking (Not reading bugmail) 2012-06-30 03:20:06 UTC
Something like createObjectStore("store", { keyPath: [] }) is completely useless and so we should throw. Likewise for createIndex("index", [])
Comment 1 Joshua Bell 2012-07-02 15:35:57 UTC
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?
Comment 2 Odin Hørthe Omdal 2012-07-05 17:20:57 UTC
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.
Comment 3 Jonas Sicking (Not reading bugmail) 2012-07-06 07:25:19 UTC
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.
Comment 4 Jonas Sicking (Not reading bugmail) 2012-07-06 07:29:19 UTC
"" and [""] *should* throw for { x: 1, y: 2 } by the way. The keyPath "" returns the value itself, and objects aren't valid keys
Comment 5 Odin Hørthe Omdal 2012-07-06 08:37:56 UTC
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.
Comment 6 Jonas Sicking (Not reading bugmail) 2012-07-06 22:44:06 UTC
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"

would throw SyntaxError exceptions.
Comment 7 Odin Hørthe Omdal 2012-07-08 15:51:26 UTC
Yeah, looks good. SyntaxError is what we're throwing since a week ago, so no-change if that is the resolution :P
Comment 8 Joshua Bell 2012-07-09 19:06:39 UTC
Sounds good here too - just landed a patch to throw SyntaxError (well, DOMException.SYNTAX_ERR) for this in WebKit.
Comment 9 Israel Hilerio [MSFT] 2012-07-13 00:25:06 UTC
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).
Comment 10 Jonas Sicking (Not reading bugmail) 2012-07-13 00:35:24 UTC
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.
Comment 11 Israel Hilerio [MSFT] 2012-07-13 19:04:16 UTC
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.
Comment 12 Jonas Sicking (Not reading bugmail) 2012-07-13 19:49:03 UTC
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".
Comment 13 Israel Hilerio [MSFT] 2012-07-13 23:54:51 UTC
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.
Comment 14 Jonas Sicking (Not reading bugmail) 2012-07-15 21:26:12 UTC
Comment 15 Odin Hørthe Omdal 2012-09-21 14:10:37 UTC
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.
Comment 16 Jonas Sicking (Not reading bugmail) 2012-09-22 01:49:45 UTC
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.