Re: [IndexedDB] Multi-value keys

The biggest hole I see, even larger than sorting other types, is what
we use for string comparisons. In CouchDB we use the unicode collation
algorithm which is heavy but very well defined and works across
various localizations.


On Fri, Jun 18, 2010 at 5:26 PM, Jonas Sicking <> wrote:
> I didn't take it as opposing at all. I figured you'd like it as I
> based it on your description of how you do it in CouchDB ;-)
> I just wanted to make sure that we nail down all the details,
> including the sorting order, so if you see anything wrong definitely
> point it out!
> / Jonas
> On Fri, Jun 18, 2010 at 5:22 PM, Mikeal Rogers <> wrote:
>> Reading back over my email is sounds opposing and that wasn't my
>> intention, it was a long way of saying +1 and giving an explanation
>> for why we went with the same approach in CouchDB.
>> -Mikeal
>> On Fri, Jun 18, 2010 at 5:06 PM, Jonas Sicking <> wrote:
>>> On Fri, Jun 18, 2010 at 5:03 PM, Mikeal Rogers <> wrote:
>>>> The complex keys are how we do this in CouchDB as well. But, again,
>>>> the sorting algorithm needs to be well defined in order for it work.
>>>> Most pertinent to your example is how arrays of varying length might
>>>> be ordered, for instance range queries over your example would break
>>>> for [firstName, lastName] if an entry omitted lastName and arrays were
>>>> sorted by length and then by comparison of each item. This is why the
>>>> CouchDB collation algorithm sorts:
>>>> ["a"]
>>>> ["b"]
>>>> ["b","c"]
>>>> ["b","c", "a"]
>>>> ["b","d"]
>>>> ["b","d", "e"]
>>> How is that different from what I proposed? I think that was what I
>>> intended to propose, but I might be missing some edge cases :)
>>> I take it that ["a", "z"] would be sorted between ["a"] and ["b"]?
>>> / Jonas

Received on Saturday, 19 June 2010 00:30:59 UTC