[
https://issues.apache.org/jira/browse/LUCENE-6228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16255444#comment-16255444
]
Robert Muir commented on LUCENE-6228:
-------------------------------------
{quote}
This just moves the existing problem with getChildren() to the new interface
though? I think I'd rather leave it on Scorer and make it accessible through
IndexSearcher or something similar in a follow-up issue. I can change the tests
in question to not use Collectors.
{quote}
I don't think it does, i think it fixes the API? Instead of the following on
Scorer:
{code}
Collection<ChildScorer> getChildren();
class ChildScorer {
Scorer child;
relationship;
}
{code}
we should have on Scorable:
{code}
Collection<ChildScorer> getChildren();
class ChildScorer {
Scorable child;
relationship;
}
{code}
This means that getChildren becomes "safe" and you can't call methods on Scorer
that you shouldnt be invoking. As far as I understand, its part of the
motivation behind this whole issue.
> 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: [email protected]
For additional commands, e-mail: [email protected]
