Re: [IndexedDB] KeyPaths and missing properties.

On Thu, May 20, 2010 at 3:55 PM, Andrei Popescu <andreip@google.com> wrote:

> Hi,
>
> On Thu, May 20, 2010 at 10:47 AM, Jeremy Orlow <jorlow@chromium.org>
> wrote:
> > On Thu, May 20, 2010 at 1:24 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> >> It seems like there would be a lot of edge cases to define here. First
> >> of all, how is the value passed in to this expression? Do we say that
> >> it's available through some "value" variable? So that if you want to
> >> index on the "foo" property, you pass in an expression like
> >> "value.foo"? Or do we want the value to be the global object, so that
> >> if you wanted to index on the "foo" property the expression would
> >> simply be "foo"?
> >
> > Since we're already talking about requiring that data being inserted into
> > objectStores with a keyPath (for its primary key or in one of its
> indexes),
> > setting it as the global object seems reasonable.  And it matches what's
> > currently specced for the simple 1 entityStore entry to 1 index entry
> (per
> > index) case.
> >>
> >> Also, what happens if the javascript expression modifies the value?
> >> Does the implementation have to clone the value before calling each
> >> "index expression"?
> >
> > In order of how much I like the idea:
> > 1) In an ideal world, we'd spec it to be read only, but I'm not sure if
> most
> > JS engines have an easy way to do something like that.
> > 2) Another possibility is to make the order in which indexes are
> processed
> > deterministic.  That way, if someone does modify it, it'll at least
> > be consistent.
> > 3) Cloning is another possibility, but it seems like it'd have a
> performance
> > impact.  Maybe optimized implementations could copy-on-write it, though?
> >
>
>
> While it's true that allowing the keyPath to be any javascript
> expression would be very elegant and flexible (although probably quite
> difficult to explain in the spec), maybe it's worth considering a
> simpler solution? For instance, could the keyPath be simply an array
> of strings, with each string denoting the name of a property of the
> objects in the store. So in Jonas' example:
>
> { id: 5, givenName: "Benny", otherNames: ["Göran", "Bror"],
> familyName: "Andersson", age: 63, interest: "Music" }
>
> The keyPath could be set to
>
> ["givenName", "otherNames", "familyName"].
>
> The indexable data for this record would therefore be {"Benny",
> "Göran", "Bror", "Andersson"}.
>

If we're OK making the script depend on JavaScript, I still like my
suggestion a bit better.  But assuming we're not, I think this would be a
fine way to solve the problem.

Btw, if we're not depending on JavaScript, then whether or not we change any
of this, we'll need to essentially spec our own language for the keyPath.
 (As far as I can tell, there's no normative language for the parsing of
keyPath strings in the current spec.  And if we're trying not to depend on
JavaScript, we'll basically have to explain the parsing and how it maps to
objects in a completely language independent fashion.)

J