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.
I'm not claiming that this is a stellar idea, only one that might
be feasible for a specific use case.
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 <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]>
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
