11269 2010-11-09 00:38:52 +0000 Evaluating keyPaths needs to be better specified 2015-04-09 21:51:05 +0000 1 1 1 Unclassified WebAppsWG Indexed Database API unspecified PC All RESOLVED FIXED P2 normal --- 1 jonas dave.null jorlow mike public-webapps timm public-webapps-bugzilla oldest_to_newest 42292 0 jonas 2010-11-09 00:38:52 +0000 This bug is very similar to bug 9832, however since that bug is discussing a lot of related issues, I wanted to file a separate one to make sure this isn't forgotten. Currently the syntax for parsing a keyPath isn't explicitly defined. It is clear that for keypath/object "foo.bar.baz" { foo: { bar: { baz: 4 } } } the result is 4. However does keypath/object "foo[1].bar" { foo: [ false, { bar: 4 }, true ] } evaluate to 4? What about "foo[x].bar" { foo: [ { bar: 4 } ], x: 0 } or "" 4 Do either of those evaluate to 4? The last example could be useful when out-of-line keys are used, but still wanting to be able to search on the stored value. 42297 1 jonas 2010-11-09 01:03:42 +0000 A couple of more keypath/object edge cases that needs to be defined: "foo[1]" { foo: [12, 13] } "foo[5]" { foo: [12, 13] } "foo.1" { foo: [12, 13] } (i.e. is this a syntax error or not?) "[1]" [12, 13] 47080 2 jorlow 2011-03-31 18:27:02 +0000 We decided on this in some thread: <identifier> ["." <identifier>]* Where identifier is basically a JavaScript identifier (which I believe is something like this: [a-zA-Z_][a-zA-Z0-9_]* But I'm hoping we can avoid speccing this later part ourselves. 47082 3 jorlow 2011-03-31 18:27:21 +0000 *** Bug 9832 has been marked as a duplicate of this bug. ***