[
https://issues.apache.org/jira/browse/LUCENE-6228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16255640#comment-16255640
]
Alan Woodward commented on LUCENE-6228:
---------------------------------------
bq. What we need to prevent is someone calling advance() based on the results
of getChildren
But the current patch does that by just not having getChildren() on Scorable.
And just as you can get round that by casting, you could cast ChildScorer.child
to a Scorer as well if you wanted to.
I guess the disagreement is over what the getChildren() API is actually for.
The tests are using it to check that constant score wrappers and the like are
still giving us the correct root scorer, so I think casting is OK there?
Another idea I had was to replace getChildren() entirely with a visitor API,
and have a method like IndexSearcher.explain(). So you call
searcher.visitScorers(Query q, int doc, ScorerVisitor visitor) and it will then
visit all the scorers that are positioned on that doc. Maybe I should open
another issue to deal with that first?
> 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
