Re: [IndexedDB] KeyPaths and missing properties.

On Wed, May 19, 2010 at 5:24 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Wed, May 19, 2010 at 4:58 PM, Jeremy Orlow <jorlow@chromium.org> wrote:
>> On Wed, May 19, 2010 at 9:38 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>>
>>> On Wed, May 19, 2010 at 2:36 AM, Jeremy Orlow <jorlow@chromium.org> wrote:
>>> > Interesting you'd bring this up.  Andrei and I were just looking at
>>> > indexes
>>> > as specced and wondered whether it still makes sense to allow indexes to
>>> > not
>>> > have a keyPath.
>>>
>>> I think so. Consider for example a objectStore that contains entries like:
>>>
>>> { name: "Elvis Presley", born: "1935-1-8", death: "1977-8-16" }
>>>
>>> But index on how old the person was when he/she died. I guess you
>>> could require that people store a property containing the age, however
>>> it seems unfortunate to require modifying the stored data.
>>>
>>> Worse, you might have entries like:
>>>
>>> { id: 5, givenName: "Benny", otherNames: ["Göran", "Bror"],
>>> familyName: "Andersson", age: 63, interest: "Music" }
>>>
>>> in order to search for people, you might want to search for a name, no
>>> matter if that is a given name, a family name, or second name.
>>> Currently you can accomplish this by inserting 4 entries into an
>>> index, all pointing to the same entry in the objectStore. I can't
>>> think of a sane way to accomplish this using only keyPath.
>>
>> I think the main use case here is the need to allow an unknown quantity of
>> entries in the index to one entry in the objectStore.  What if we allowed
>> keyEntry's to be any javascript expression and allow them to return arrays
>> of indexible data.  In this case, the expression would return an array of
>> otherNames + the givenName + the familyName.  The keyPath already is
>> essentially just a javascript expression, so this doesn't seem like too big
>> of a leap.
>> This would also support your age upon death use case.  (Though I think
>> requiring the developer to store that age if they want it indexed isn't too
>> bad of an answer either.)
>> Thoughts?
>
> I think it's an interesting idea, and one that came up when we were
> talking to developers way back before IndexedDB spec was started.
> However then we more discussed it in the sense that libraries would be
> using the technique, rather than that the API would use it.
>
> The problem with using a javascript expression is how do you provide
> it? If you're allowed to pass in a function, that also means that
> you're pulling in the full scope of that function. This obviously
> doesn't work since the index generally outlives the scope and is used
> in other browsing sessions and other tabs.
>
> So you'd have to pass in the javascript expression as a string. This
> certainly works but is more than a little ugly. It also complicates
> the implementation a good bit since it now has to include a javascript
> engine. Not a huge issue given that all browsers has one anyway, but
> feels a bit iffy.
>
> I still think it's an interesting idea, though I'm not sold on it.
> Especially for the first version of the spec.

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"?

Also, what happens if the javascript expression modifies the value?
Does the implementation have to clone the value before calling each
"index expression"?

/ Jonas

Received on Thursday, 20 May 2010 00:40:31 UTC