On Sun, Oct 5, 2008 at 7:48 PM, Chris Anderson <[EMAIL PROTECTED]> 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... Because I don't know at design time how many secondary keys there will be per primary key, or even how many keys there will be. > > > 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 >
