- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 20 May 2010 08:56:31 -0700
- To: Andrei Popescu <andreip@google.com>
- Cc: Jeremy Orlow <jorlow@chromium.org>, Webapps WG <public-webapps@w3.org>
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