[
https://issues.apache.org/jira/browse/LUCENE-5307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13806037#comment-13806037
]
ASF subversion and git services commented on LUCENE-5307:
---------------------------------------------------------
Commit 1535950 from [~thetaphi] in branch 'dev/trunk'
[ https://svn.apache.org/r1535950 ]
LUCENE-5307: Fix topScorer inconsistency in handling QueryWrapperFilter inside
ConstantScoreQuery, which now rewrites to a query removing the obsolete
QueryWrapperFilter
> 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
> Components: core/search
> Reporter: Adrien Grand
> Assignee: Uwe Schindler
> Priority: Minor
> Fix For: 4.6, 5.0
>
> Attachments: LUCENE-5307.patch, LUCENE-5307.patch,
> LUCENE-5307-test.patch
>
>
> {{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
