We can only guess what Jason had in mind at step 3. Lucene can sort by any appropriately indexed field but here, as in the single-pass map/reduce view, the value you want is not available.
I think someone had a crack at chained map-reduce other than Cloudant but I don't recall the project name. Also, I know Benoit is working on adding a _changes feed for views, which should allow chained m-r too. B. On 27 March 2012 18:28, nicholas a. evans <[email protected]> wrote: > On Tue, Mar 27, 2012 at 1:14 PM, Robert Newson <[email protected]> wrote: >> cross-posting is generally bad form as it splits the conversation. If >> I answer here or on SO, someone potentially loses out. > > Good point. Sorry about that. > >> That said, couchdb-lucene is an independent index, sourced from the >> database. As such, it has no access to the reduced values nor does it >> have an equivalent feature. Where did you see that suggestion? > > I saw that suggestion at http://stackoverflow.com/a/2821476/110681 > > I think the idea wasn't so much that couchdb-lucene would read from > the view as much that couchdb-lucene would give me a completely > different way to approach the problem. Is there some way for lucene > to index the data so that it could give me ranked results? E.g. if > every document has a doc.sender, is there some way to store the > senders in lucene and then ask for a ranking of senders with their > counts? I don't know enough about lucene or full-text indexing in > general, so I hoped and assumed there might be some way to twist the > lucene index to do my bidding. :) > > If lucene can't help out and no one knows of an open source chained > map-reduce views implementation, then the polyglot persistence > approach sounds best to me, since redis zsets are perfect for this > particular task. > > Thanks. > -- > Nick
