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
