Adrien Grand created LUCENE-5307: ------------------------------------ Summary: Inconsistency between Weight.scorer documentation and ConstantScoreQuery on top of a Filter Key: LUCENE-5307 URL: https://issues.apache.org/jira/browse/LUCENE-5307 Project: Lucene - Core Issue Type: Bug Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor
{{Weight.scorer}} states that if {{topScorer == true}}, {{Scorer.collect}} will be called and that otherwise {{Scorer.nextDoc/advance}} will be called. This is a problem when {{ConstantScoreQuery}} is used on top of a {{QueryWrapperFilter}}: 1. {{ConstantScoreWeight}} calls {{getDocIdSet}} on the filter to know which documents to collect. 2. {{QueryWrapperFilter.getDocIdSet}} returns a {{Scorer}} created with {{topScorer == false}} so that {{nextDoc/advance}} are supported. 3. But then {{ConstantScorer.score(Collector)}} has the following optimization: {code} // this optimization allows out of order scoring as top scorer! @Override public void score(Collector collector) throws IOException { if (docIdSetIterator instanceof Scorer) { ((Scorer) docIdSetIterator).score(wrapCollector(collector)); } else { super.score(collector); } } {code} So the filter iterator is a scorer which was created with {{topScorer = false}} but {{ParentScorer}} ends up using its {{score(Collector)}} method, which is illegal. (I found this out because AssertingSearcher has some checks to make sure Scorers are used accordingly to the value of topScorer.) I can imagine several fixes, including: - removing this optimization when working on top of a filter - relaxing Weight documentation to allow for using {{score(Collector)}} when {{topScorer == false}} but I'm not sure which one is the best one. What do you think? -- This message was sent by Atlassian JIRA (v6.1#6144) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org