Re: [IndexedDB] KeyPaths and missing properties.

On Thu, May 20, 2010 at 7:55 AM, 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"}.

This wouldn't solve the case when the key is the result of a
calculation, such as my age-at-time-of-death example. Consider also
wanting to store objects like

{ id: 5, name: "Benny Andersson", address: "1 Ohai Street\n Wahiawa, HI 96786" }

but wanting to index on the first name or on the state in the address.

/ Jonas

Received on Thursday, 20 May 2010 15:57:30 UTC