Re: [IndexedDB] Multi-value keys

On Fri, Jun 18, 2010 at 7:13 PM, Jeremy Orlow <jorlow@chromium.org> wrote:
> Another possible meaning for arrays is allowing someone to insert multiple
> values into an index that point to one object store.  For example:
> { names: ["Sarah", "Jessica", "Parker"], ...}
> { names: ["Bono"], ...}
> { names: ["Jonas", "Sicking"], ...}
> Then I could look up "Sicking" inside an index with a keyPath of "names" and
> find Jonas even though I didn't know whether I was looking for his first
> name or last.
> I'm not sure whether creating semantics like this (or at least reserving the
> possibility for them in the future) is worth not using indexes as Jonas
> proposed, but it's worth considering.
>
> I'm also not so hot on the idea that if I want to index into something I
> either need to duplicate/mangle data in order to use keyPath or do explicit
> key management (which I'm not so hot on in general).  I wonder if we could
> define keyPath to take some sort of array like syntax so that your example
> could work via a keyPath of "[firstName, lastName]" instead.  Of course then
> the spec for the keyPath syntax is more complex.

This is what Pablo suggested. Though he suggested the syntax
["firstName", "lastName"] which I think is a better idea as then we
won't need to get into parsing strings more than we already are.

I agree that duplicating or mangling data is not ideal, which is why I
made the suggestion in [1]. I think this is an ok solution for the
case when you have a property that contains a list and you want to add
each entry to the index.

> I'm sold on the need for ways to do composite indexes, but I'm not sure what
> the best way to express them will be.  The fact that couchDB allows indexing
> on arrays definitely makes me lean towards your proposal though, Jonas.

Cool!

[1] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/1094.html

/ Jonas

Received on Saturday, 19 June 2010 06:39:31 UTC