-
Notifications
You must be signed in to change notification settings - Fork 3.6k
HHH-19497 Test for composition of 'not' 'in' restrictions #10412
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
HHH-19497 Test for composition of 'not' 'in' restrictions #10412
Conversation
…me, this test fails for dialects that do not support record-level construction, such as DB2Dialect.
@beikov would you take a look at this one please? |
getSqlTuple( expression ).getExpressions(), | ||
comparisonOperator, | ||
SqlTupleContainer.getSqlTuple(expression).getExpressions(), | ||
ComparisonOperator.EQUAL, | ||
true | ||
); | ||
separator = " or "; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the fix and test. I'm just curious why you didn't change the junction type here instead. Am I missing some subtle case where using not ( (x=x1 and y=y1) or (x=x2 and y=y2) )
is "more" correct over ( (x<>x1 or y<>y1) and (x<>x2 or y<>y2) )
?
separator = " or "; | |
separator = inListPredicate.isNegated() ? " and " : " or "; |
I also did some testing with null
values on PostgreSQL and to me it seems that both kinds of expressions are semantically equivalent. With an increasing amount of in-list items (3+), the not
approach is more compact, which is why I would even prefer that. Since you seem to be on DB2, could you please let me know if there is a performance difference between the two predicate styles i.e. are the query execution plans the same?
3c5e512
to
da84610
Compare
…HHH-19497-negated-in-list # Conflicts: # hibernate-core/src/main/java/org/hibernate/sql/ast/spi/AbstractSqlAstTranslator.java
not in is not handled correctly for multi-column joins. This pull request fixes the problem.
Compositions of not with in on lists fail for dialects not supporting record-level construction, such as DB2Dialect.
Using not with in with such dialects can lead to dangerous outcomes, such as all records being returned from a query. This is because the query condition always evaluates to either true or false (depending on the details of the query) because multi-column joins are not handled correctly.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license
and can be relicensed under the terms of the LGPL v2.1 license in the future at the maintainers' discretion.
For more information on licensing, please check here.
https://hibernate.atlassian.net/browse/HHH-19497