lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Muir (JIRA)" <>
Subject [jira] [Commented] (LUCENE-6229) Remove Scorer.getChildren?
Date Fri, 20 Feb 2015 15:55:12 GMT


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:
>             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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message