[ 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org