Re: [IndexedDB] Multi-value keys

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.


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.

J

On Fri, Jun 18, 2010 at 4:08 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> Hi All,
>
> One thing that (if I'm reading the spec correctly) is currently
> impossible is to create multi-valued keys. Consider for example an
> object store containing objects like:
>
> { firstName: "Sven", lastName: "Svensson", age: 57 }
> { firstName: "Benny", lastName: "Andersson", age: 63 }
> { firstName: "Benny", lastName: "Bedrup", age: 9 }
>
> It is easy to create an index which lets you quickly find everyone
> with a given firstName or a given lastName. However it doesn't seem
> possible to create an index that finds everyone with a given firstName
> *and* lastName, or sort the list of people based on firstName and then
> lastName.
>
> The best thing you could do is to concatenate the firstname and
> lastname and insert a ascii-null character in between and then use
> that as a key in the index. However this doesn't work if firstName or
> lastName can contain null characters. Also, if you want to be able to
> sort by firstName and then age there is no good way to put all the
> information into a single string while having sorting work.
>
> Generally the way this is done in SQL is that you can create an index
> on multiple columns. That way each row has multiple values as the key,
> and sorting is first done on the first value, then the second, then
> the third etc.
>
> However since we don't really have columns we can't use that exact
> solution. Instead, the way we could allow multiple values is to add an
> additional type as keys: Arrays.
>
> That way you can use ["Sven",  57], ["Benny", 63] and ["Benny", 9] as
> keys for the respective objects above. This would allow sorting and
> searching on firstName and age.
>
> The way that array keys would be compared is that we'd first compare
> the first item in both arrays. If they are different the arrays are
> ordered the same way as the two first-values are order. If they are
> the same you look at the second value and so on. If you reach the end
> of one array before finding a difference then that array is sorted
> before the other.
>
> We'd also have to define the order if an array is compared to a
> non-array value. It doesn't really matter what we say here, but I
> propose that we put all array after all non-arrays.
>
> Note that I don't think we need to allow arrays to contain arrays.
> That just seems to add complication without adding additional
> functionality.
>
> Let me know what you think.
>
> / Jonas
>
>