[jira] [Updated] (LUCENE-5307) Inconsistency between Weight.scorer documentation and ConstantScoreQuery on top of a Filter

["Adrien Grand (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/LUCENE-5307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Adrien Grand updated LUCENE-5307:
---------------------------------

    Attachment: LUCENE-5307-test.patch

Here is a test that fails (feel free to not reuse it, this is just to demonstrate the problem).

> 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: Uwe Schindler
>            Priority: Minor
>         Attachments: 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org