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: [email protected]
For additional commands, e-mail: [email protected]
