On Tue, Nov 9, 2010 at 3:38 AM, <[email protected]> wrote:
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=11269
>
> Summary: Evaluating keyPaths needs to be better specified
> Product: WebAppsWG
> Version: unspecified
> Platform: PC
> OS/Version: All
> Status: NEW
> Severity: normal
> Priority: P2
> Component: Indexed Database API
> AssignedTo: [email protected]
> ReportedBy: [email protected]
> QAContact: [email protected]
> CC: [email protected], [email protected]
>
>
> 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
>
Chromium supports all of the examples you've listed so far. Making it more
restrictive could be a good idea though. Does anyone have specific
thoughts?
> "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.
>
This seems like a bit of a stretch for v1.
J
