[
https://issues.apache.org/jira/browse/LUCENE-5409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13882104#comment-13882104
]
Michael McCandless commented on LUCENE-5409:
--------------------------------------------
bq. I never rewrite myself (so does most of lucene users) but
IndexSearcher.rewrite method used in search(...) will rewrite any query
recursively until it reaches the final stage.
Ahh, right.
But still I'm confused how this would tickle the bug. Clearly the bug is
there, and we should be passing origChildQuery as the first arg when we
rewrite, but I'd still like a small test case here showing the issue, somehow
...
> ToParentBlockJoinCollector.getTopGroups returns empty Groups
> ------------------------------------------------------------
>
> Key: LUCENE-5409
> URL: https://issues.apache.org/jira/browse/LUCENE-5409
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/search
> Affects Versions: 4.6
> Environment: Ubuntu 12.04
> Reporter: Peng Cheng
> Assignee: Michael McCandless
> Priority: Critical
> Fix For: 4.7
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> A bug is observed to cause unstable results returned by the getTopGroups
> function of class ToParentBlockJoinCollector.
> In the scorer generation stage, the ToParentBlockJoinCollector will
> automatically rewrite all the associated ToParentBlockJoinQuery (and their
> subqueries), and save them into its in-memory Look-up table, namely
> joinQueryID (see enroll() method for detail). Unfortunately, in the
> getTopGroups method, the new ToParentBlockJoinQuery parameter is not
> rewritten (at least users are not expected to do so). When the new one is
> searched in the old lookup table (considering the impact of rewrite() on
> hashCode()), the lookup will largely fail and eventually end up with a
> topGroup collection consisting of only empty groups (their hitCounts are
> guaranteed to be zero).
> An easy fix would be to rewrite the original BlockJoinQuery before invoking
> getTopGroups method. However, the computational cost of this is not optimal.
> A better but slightly more complex solution would be to save unrewrited
> Queries into the lookup table.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
