[jira] [Updated] (LUCENE-6228) Do not expose full-fledged scorers in LeafCollector.setScorer

["Alan Woodward (JIRA)" <ji...@apache.org>]

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

Alan Woodward updated LUCENE-6228:
----------------------------------
    Attachment: LUCENE-6228.patch

Here's a patch implementing [~rcmuir]'s idea of a Scorable interface.  This seems like the least intrusive way of doing this?

As this changes LeafCollector, which is a fairly heavily-used part of the API, I think this should only apply to master

> Do not expose full-fledged scorers in LeafCollector.setScorer
> -------------------------------------------------------------
>
>                 Key: LUCENE-6228
>                 URL: https://issues.apache.org/jira/browse/LUCENE-6228
>             Project: Lucene - Core
>          Issue Type: Improvement
>            Reporter: Adrien Grand
>            Assignee: Adrien Grand
>             Fix For: 5.2, 6.0
>
>         Attachments: LUCENE-6228.patch, LUCENE-6228.patch, LUCENE-6228.patch, LUCENE-6228.patch
>
>
> Currently LeafCollector.setScorer takes a Scorer, which I don't like because several methods should never be called in the context of a Collector (like nextDoc or advance).
> I think it's even more trappy for methods that might seem to work in some particular cases but will not work in the general case, like getChildren which will not work if you have a specialized BulkScorer or iterating over positions which will not work if you are in a MultiCollector and another leaf collector consumes positions too.
> So I think we should restrict what can be seen from a collector to avoid such traps.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org