Hi Gary, Yes, unfortunately, this is a bug. (Tracked here: https://issues.basho.com/show_bug.cgi?id=867) We have not yet scheduled the fix for this.
Best, Rusty On Mon, Feb 28, 2011 at 1:25 AM, Gary William Flake <g...@flake.org> wrote: > Ack. I know what's happening with this. Riaksearch is sorting by > relevance, segmenting the results according to start and rows, and THEN > sorting by the sort key. > > Is this the intended behavior? If so, I am kind of surprised because the > post sort is easy for the caller to do without Riaksearch's help. What's > hard is the pre-sort. > > I suppose the work around is to get all of the results, then send the > result to map/reduce to correctly handle pre-sort, then filter by range. > However, before I do this, does anyone know if (a) this is considered > broken? and (b) if so, is this scheduled to be fixed? > > Thanks, > -- GWF > > > > On Sun, Feb 27, 2011 at 10:17 PM, Gary William Flake <g...@flake.org>wrote: > >> While coding up a front-end to paginate over a set of search results, I >> think I found a bug whereby the result set is incorrectly segmented as a >> function of the sort key, the start index, and the row count. In the output >> that follows, I am using the field ctime for sort order, and the value of >> delta is simply the difference between subsequent ctime values (which I was >> checking in order to debug what was happening). >> >> First, lets ask for just the first result: >> >> GET >>> /solr/clips/select?q=user%3Ad33af3cca29a43e63e8f6a52dfdd99a61f7b7906%20AND%20private%3A1&start=0&rows=1&wt=json&sort=ctime >> >> >>> title: weather flagler beach - Google Search >> >> ctime: 98701733411258 >> >> delta: 0 >> >> ---------- >> >> >> >> Now, let's do the same query, but get the top three instead: >> >> GET >>> /solr/clips/select?q=user%3Ad33af3cca29a43e63e8f6a52dfdd99a61f7b7906%20AND%20private%3A1&start=0&rows=3&wt=json&sort=ctime >> >> >>> title: Amazon.com: knives >> >> ctime: 98701733349673 >> >> delta: 0 >> >> ---------- >> >> title: weather flagler beach - Google Search >> >> ctime: 98701733411258 >> >> delta: 61585 >> >> ---------- >> >> title: Bartholdi on spacefilling curves >> >> ctime: 98701733465867 >> >> delta: 54609 >> >> ---------- >> >> >> >> Notice that we have a new 'top' result. Finally, let's get all of the >> results by setting row to something large, but I'll only show the first >> result because that's all you need to see: >> >> GET >>> /solr/clips/select?q=user%3Ad33af3cca29a43e63e8f6a52dfdd99a61f7b7906%20AND%20private%3A1&start=0&rows=1000&wt=json&sort=ctime >> >> >>> title: HTTP cookie - Wikipedia, the free encyclopedia >> >> ctime: 98701587317266 >> >> delta: 0 >> >> ---------- >> >> >> >> We now get a record that we haven't seen yet. >> >> >> I can confirm that when I get all of the results, they are in the properly >> sorted order. I also believe that any of my smaller result sets are also in >> proper sort order. However, it also appears that when I ask for a specific >> number of row with a non-zero start start value, then the start index is not >> handled correctly. FWIW, these results don't' have anything to do with the >> client library because I reproduced them over the REST interface. >> >> Any ideas? >> >> -- GWF >> > >
_______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
