Re: [IndexedDB] Multi-value keys

I'm currently building out the CouchDB API on top of IndexedDB and
achieving this particular use case is pretty trivial.

I would just process a map function like:

function (doc) { doc.names.forEach(function(n){emit(n, 1)})} ;

Then I would process that map function and create an index with each
key/value and a reference back to the document that was used to create
the index. When I pull out the "view" I would optionally also pull out
the originating document from the other objectStore.

I think it's simple enough to do on top of the existing API that I
wouldn't want to exclude Jonas' use case, or complicate things by
specifying sorting of JSON style arrays inside the string sorting
algorithm.

-Mikeal

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.
>
> 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
>>
>
>

Received on Saturday, 19 June 2010 06:25:40 UTC