[
https://issues.apache.org/jira/browse/LUCENE-7810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martijn van Groningen updated LUCENE-7810:
------------------------------------------
Attachment: LUCENE_7810.patch
[~jpountz] I've updated the patch. Score mode is now taken into account in
equals(...) and hashcode(...) methods and in case a scoring query is used when
no scores are needed then it the query gets replaced with the non scoring
variant.
> false positive equality: distinctly diff join queries return equals()==true
> ---------------------------------------------------------------------------
>
> Key: LUCENE-7810
> URL: https://issues.apache.org/jira/browse/LUCENE-7810
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Hoss Man
> Attachments: LUCENE_7810.patch, LUCENE_7810.patch, LUCENE-7810.patch
>
>
> While working on SOLR-10583 I was getting some odd test failures that seemed
> to suggest we were getting false cache hits for Join queries that should have
> been unique.
> tracing thorugh the code, the problem seems to be the way {{TermsQuery}}
> implements {{equals(Object)}}. This class takes in the {{fromQuery}} (used
> to identify set of documents we "join from") and uses it in the equals
> calculation -- but the information about the join _field_ is never passed
> directly to {{TermsQuery}} and the BytesRefs that are passed in can't be
> compared efficiently (AFAICT), so 2 completely diff calls to
> {{JoinUtils.createJoinQuery(...)}} can result in Query objects that think
> they are {{equal()}} even when they most certainly are not.
> At a brief glance, it appears that similar bugs exist in
> {{TermsIncludingScoreQuery}} (and possibly {{GlobalOrdinalsWithScoreQuery}},
> but i didn't look into that class at all)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
