This is tricky (and even now I wrote this email twice). It is all about mating a Scorer and Collector together:
* Any out-of-order Scorer can be fed into an acceptsOutOfOrder Collector. * Any in-order Scorer can be fed into either accepts=true/false Collector. Therefore, when Weight is *queried* about its orderness, the answer has to be definite. So if we named the method weight.scoresDocsInOrder and you got true, you can't know for sure if the docs will be scored out-of-order or in-order only, while we felt that scoresDocsOutOfOrder is more definite --> i.e. you can't return false and score docs out-of-order, and you can't return true and score docs in-order ... When you create TSDC, you want to tell it for sure how docs will be scored, because it needs to be the most optimized it can. Therefore the parameter is docsScoredInOrder. If it was docsScoredOutOfOrder, a Scorer could still return the docs in-order, and TSDC would use the less optimized impl. I hope I've managed to explain it ... gosh - even now I need to think twice before I type a sentence :) Shai On Mon, Aug 24, 2009 at 7:56 PM, Mark Miller <markrmil...@gmail.com> wrote: > Mark Miller wrote: > >> > >> * > >> * @param docsScoredInOrder > >> * specifies if documents will be scored in doc ID order by > the > >> * query. If you're not sure in advance, you can do the > >> following: > >> * <pre> > >> * boolean docsScoredInOrder = > >> !q.weight(searcher).scoresDocsOutOfOrder(); > >> * TopScoreDocCollector tsdc = > >> TopScoreDocCollector.create(numHits, docsScoredInOrder); > >> * </pre> > >> * > >> * @see Weight#scoresDocsOutOfOrder() > >> > >> > >> > Any reason for the reversal? eg weight.scoreOutOfOrder to > TopScoreDocCollector.scoreInOrder? > > -- > - Mark > > http://www.lucidimagination.com > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > >
