HQL null literal comparison change in regards to parameters

Hibernate ORM
1

As stated in the 6.3 migration guide, the way Hibernate compares null literals has been changed to the SQL default. Previously a SELECT p FROM Parent p WHERE p.child = :child would find all parents without children if null was passed as parameter child, whereas now no results are returned.

Our application has over 2000 queries. We are worried, that this change might lead to a change in behavior of some of our code. If there is code passing null as a parameter, it might be an error, or it might even be intended. We can’t be sure and we can’t really check all queries with their accompanying logic.

Our idea was to write an interceptor or similar that runs at a time before the query is executed, but the parameters have already been set. We would need access to either the HQL query (preferred) or the SQL translation and the parameters. We would like to parse the query, analyze the parameters and log a warning or throw an exception if the case meets our criteria.

Are there ways to accomplish that, what are they, and how can they be implemented?

Thank you very much in advance!

2

Previously a SELECT p FROM Parent p WHERE p.child = :child would find all parents without children if null was passed as parameter child , whereas now no results are returned.

This is not correct and is exactly the reason why we changed the behavior.

.. where some = null was specially treated to mean .. where some is null, but .. where some = :param was always rendered as .. where some = ? in SQL, regardless of the value you bind. Since relational operators like = produce UNKNOWN/FALSE if compared against NULL, this was never producing results if you bind null.

3

Thank you very much for your reply! That’s a relief :sweat_smile:. I just tested it on our old Hibernate version and you are, of course, absolutely correct. We should have verified our assumption before…

Just yesterday I had a case where such a query was passed null and I guess that led to a case of erroneous confirmation bias.

Thanks as always!