W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2010

Re: [IndexedDB] KeyPaths and missing properties.

From: Andrei Popescu <andreip@google.com>
Date: Thu, 20 May 2010 15:55:31 +0100
Message-ID: <AANLkTinSzJMsxcmESZ6WTgiIom5uvqe3ACcmaVsArj1x@mail.gmail.com>
To: Jeremy Orlow <jorlow@chromium.org>
Cc: Jonas Sicking <jonas@sicking.cc>, Webapps WG <public-webapps@w3.org>
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"}.


Thanks,
Andrei
Received on Thursday, 20 May 2010 14:56:05 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:38 GMT