Mailing-List: contact couchdb-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: couchdb-user@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <a01fc5d10810051236p5fd426feif9c658924b218e4b@mail.gmail.com>
Date: Sun, 5 Oct 2008 20:36:39 +0100
From: "Nick Johnson" <arachnid@notdot.net>
To: couchdb-user@incubator.apache.org
Subject: Re: Sorting views with composite keys
In-Reply-To: <60FF2718-50A6-4909-BEA2-B9B5E8F74533@apache.org>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_28866_29702321.1223235400008"
References: <a01fc5d10810050925l3d9a2391hd2b8df2182689525@mail.gmail.com>
	 <e282921e0810051126j2ac383bfjcf11d7d9bf69b688@mail.gmail.com>
	 <27d8d0930810051135j7f736c87g4b48bdbf3c86dedd@mail.gmail.com>
	 <e282921e0810051148t4c8d09c3k5ea372098bfe9b7e@mail.gmail.com>
	 <60FF2718-50A6-4909-BEA2-B9B5E8F74533@apache.org>

------=_Part_28866_29702321.1223235400008
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Sun, Oct 5, 2008 at 8:21 PM, Jan Lehnardt <jan@apache.org> wrote:

> In my defense :)
>
> My suggestion was a 3 minute hack that was done without
> much thinking. If we want to go that route, we'd need to
> add more sorting handlers for other data types. this could
> go into a view-JS standard library (like sum()).
>
> the use-case was just having the sorting by first and second key,
> but only ever query on the first one.


Well, potentially someone might limit based on the second key too, but I
have no issue with preprocessing queries in the same manner.


>
>
> I'm not claiming that this is a stellar idea, only one that might
> be feasible for a specific use case.


Indeed. I'm concerned about the overhead of converting a string into an
array of integers, though. Instinct tells me it may be worse than taking the
bitwise negation of the string and encoding that as a hex string, though.


>
>
> Cheers
> Jan
> --
>
>
> On Oct 5, 2008, at 20:48 , Chris Anderson wrote:
>
>  yeah you'd have to preprocess the keys with a similar function..
>>
>> I think the use case is that you'd query based on the front key, and a
>> count, so as to get, say the last 10 alphabetical tags for a given
>> user.
>>
>> Come to think of it, I'm not sure what sense there is in doing this.
>> Why not just use a regular collation, and if you have more per
>> front-key than you can fit in ram, just page through the front key's
>> second key in reverse...
>>
>>
>> On Sun, Oct 5, 2008 at 11:35 AM, Ayende Rahien <ayende@ayende.com> wrote:
>>
>>> How does querying those works?I mean, the keys wouldn't match, would
>>> they?
>>>
>>> On Sun, Oct 5, 2008 at 8:26 PM, Chris Anderson <jchris@apache.org>
>>> wrote:
>>>
>>>  Jan posted this to the IRC channel.
>>>>
>>>> http://friendpaste.com/rc9CcxUW
>>>>
>>>> I supposed you'd have to write a reverse method for each JS primitive
>>>> type, if you wanted to be completely flexible.
>>>>
>>>>
>>>> On Sun, Oct 5, 2008 at 9:25 AM, Nick Johnson <arachnid@notdot.net>
>>>> wrote:
>>>>
>>>>> How would I construct a view with two keys, a and b, sorted first by a
>>>>> ascending, then by b descending? Composite keys are easy enough to
>>>>>
>>>> generate,
>>>>
>>>>> but the key [a,b] would only permit sorting both in ascending order (or
>>>>>
>>>> both
>>>>
>>>>> in descending order, if we scan in reverse). Can anyone suggest a way
>>>>> of
>>>>> modifying the keys to support heterogenous sort orders like this? My
>>>>> best
>>>>> idea so far is a monstrosity involving hex-encoded binary data. :)
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Chris Anderson
>>>> http://jchris.mfdz.com
>>>>
>>>>
>>>
>>
>>
>> --
>> Chris Anderson
>> http://jchris.mfdz.com
>>
>>
>

------=_Part_28866_29702321.1223235400008--