Hi Elias, Yes, you've encountered a known bug, tracked here: https://issues.basho.com/show_bug.cgi?id=867
MapReduce is one way to solve this issue. Another approach, depending on how frequently the query changes, would be to read and cache the result set somewhere, and then paginate from there. Best, Rusty On Mon, Oct 24, 2011 at 8:44 PM, Elias Levy <fearsome.lucid...@gmail.com>wrote: > In what order are the sort and rows options of search via the Solr API > applied? > > It would appear that rows is applied first, with the cluster waiting just > long enough to receive enough answers to to fulfill the rows requirement, > and only then sorting the result set. Alas, if that is the case, then the > sort and rows parameters are useless for pagination. > > I got a query that matching around 420 objects with indexed timestamps. > I'd like to return the latest 10 objects. Thus, I use sort="ts desc" and > rows="10", but the result set I get, while sorted, does not represent the > latest objects. The only way I can get the latest objects is to make rows > as large the the number of results, use sort="ts desc" to get Riak to do the > sort, then perform the slice at the client. This will become wasteful and > slow with queries that match many more objects. > > Is this expected behavior? > > Looks like I'll have to resort to MR jobs to get the behavior I want. > > > > _______________________________________________ > riak-users mailing list > riak-users@lists.basho.com > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > > -- Rusty Klophaus *Basho Technologies, Inc.* 11921 Freedom Drive, Suite 550 Reston, VA 20190 www.basho.com
_______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com