On Mon, Oct 6, 2008 at 1:10 AM, kowsik <[EMAIL PROTECTED]> wrote: > One possibility is to add a collation function to the design document. > With this we'll have map, reduce and collate. This allows the user to > override the default collation mechanism used for a particular design > view. Seems pretty clean. The view server then becomes responsible > (using the appropriate language) to perform the sorting using > whatever's best for the view. > > Thoughts?
This seems like an excellent idea. It would also allow users to specify their own text sorting functions: https://issues.apache.org/jira/browse/COUCHDB-130 . > > K. > > On Sun, Oct 5, 2008 at 12:37 PM, Nick Johnson <[EMAIL PROTECTED]> wrote: > > 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 > >> > > >
