[jira] [Updated] (LUCENE-7810) false positive equality: distinctly diff join queries return equals()==true
[
https://issues.apache.org/jira/browse/LUCENE-7810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martijn van Groningen updated LUCENE-7810:
--
Fix Version/s: 6.6
> 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
> Fix For: master (7.0), 6.6, 6.7
>
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7810) false positive equality: distinctly diff join queries return equals()==true
[
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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7810) false positive equality: distinctly diff join queries return equals()==true
[
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
Added patch based on [~hossman]'s patch that adds more tests and fixes
{{equals()}} method in {{TermsIncludingScoreQuery}} and {{TermsQuery}}. The
global ordinal based queries did already implement {{equals()}} correctly and
the numeric join's {{equals()}} method was also working correctly because it is
comparing the actual collected points.
> 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
>
>
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7810) false positive equality: distinctly diff join queries return equals()==true
[
https://issues.apache.org/jira/browse/LUCENE-7810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated LUCENE-7810:
-
Description:
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)
was:
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)
Summary: false positive equality: distinctly diff join queries return
equals()==true (was: false equals() result for distinctly diff join queries)
updated summary that i realize now was value/missleading about the "false
positive" situation.
> 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
>
>
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
