[
https://issues.apache.org/jira/browse/LUCENE-6229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14329082#comment-14329082
]
Robert Muir commented on LUCENE-6229:
-------------------------------------
I don't understand why we quickly threw out the third option i presented: just
let getChildren() be completely transparent about where scorers are positioned,
it reflects reality and means it will not infringe on the actual query
performance. This still allows it to be used at least for debugging.
If we insist that it returns correctly positioned scorers, then honestly i
don't think it will ever happen. It will stay half-broken and undefined like
today instead. The performance cost is far too high, and specializing scors via
an option is too expensive in terms of maintenance. We already have a hard
enough time with the scorers we have.
For extremely expert use cases like using getChildren() to "subclass" a query,
there are other alternatives, considering the code is open source, like just
forking that query or whatever. At some point, something is just expert enough
where that is the correct solution to the problem.
> Remove Scorer.getChildren?
> --------------------------
>
> Key: LUCENE-6229
> URL: https://issues.apache.org/jira/browse/LUCENE-6229
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Adrien Grand
> Priority: Minor
>
> This API is used in a single place in our code base:
> ToParentBlockJoinCollector. In addition, the usage is a bit buggy given that
> using this API from a collector only works if setScorer is called with an
> actual Scorer (and not eg. FakeScorer or BooleanScorer like you would get in
> disjunctions) so it needs a custom IndexSearcher that does not use the
> BulkScorer API.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
