No, the problem is that, due to rounding, sometimes the docs ARE considered ties, and therefore the secondary sort is used, but sometimes they don't round to exactly equal, and the tiebreaker isn't used, and the results get shuffled.
Stephen Duncan Jr www.stephenduncanjr.com On Tue, Feb 22, 2011 at 6:09 PM, Geert-Jan Brits <gbr...@gmail.com> wrote: > You could always use a secondary sort as a tie-breaker, i.e: something > unique like 'documentid' or something. That would ensure a stable sort. > > 2011/2/23 Stephen Duncan Jr <stephen.dun...@gmail.com> > > > I'm trying to use > > > > > http://wiki.apache.org/solr/SolrRelevancyFAQ#How_can_I_boost_the_score_of_newer_documents > > as > > a bf parameter to my dismax handler. The problem is, the value of NOW > can > > cause documents in a similar range (date value within a few seconds of > each > > other) to sometimes round to be equal, and sometimes not, changing their > > sort order (when equal, falling back to a secondary sort). This, in > turn, > > screws up paging. > > > > The problem is that score is rounded to a lower level of precision than > > what > > the suggested formula produces as a difference between two values within > > seconds of each other. It seems to me if I could round the value to > > minutes > > or hours, where the difference will be large enough to not be > rounded-out, > > then I wouldn't have problems with order changing on me. But it's not > > legal > > syntax to specify something like: > > recip(ms(NOW,manufacturedate_dt/HOUR),3.16e-11,1,1) > > > > Is this a problem anyone has faced and solved? Anyone have suggested > > solutions, other than indexing a copy of the date field that's rounded to > > the hour? > > > > -- > > Stephen Duncan Jr > > www.stephenduncanjr.com > > >
