[
https://issues.apache.org/jira/browse/LUCENE-7810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated LUCENE-7810:
-----------------------------
Attachment: LUCENE-7810.patch
The attached patch includes a trivial test case demonstraing the bug I found --
but this only executes one code path of {{JoinUtils.createJoinQuery(...)}} --
there are almost certainly other code paths with similar bugs that should also
be tested. (see nocommit comments in test)
A few NOTEs:
# At present, due to some code I don't really understand in how Solr only
leverages JoinUtils in _rewritten_ queries, it appears that this bug does not
impact current Solr usecases. The patch also includes a trivial test showing
that the "wrapper" queries solr creates around {{JoinUtils}} don't have this
same equality problem
# i discovered this bug purely by fluke because in my originally POC code for
SOLR-10583 I used {{JoinUtils.createJoinQuery(...)}} directly instead of
refactoring Solr's {{JoinQParserPlugin}} code so i could re-use it -- doing
that refactoring is my nextstep for that issue, so I won't personally be
pursuing fixing this bug (particularly since i'm not really sure what a good
fix should look like)
> false equals() result for distinctly diff join queries
> ------------------------------------------------------
>
> 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
>
>
> 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]
