We recently did an upgrade from Hibernate 5.3.16 to Hibernate 5.4.14 inside one of our applications.
One of our enitity has a foreign key relationship inside its own table, and additionally uses discriminators for that table.
Basically we execute the following update statement:
{code :java }
update OpdrachtPlan o set o.plan.id = :newPlanId where o.plan.id = :planId and o.isProCalc = false and o.maand >= :datum
{code}
Hibernate 5.4.14 generates the following (invalid) SQL statement for this query:
{code:sql}
update
SDOPDR cross
join
set
PKSDOPDRREF=?
where
(
SDOPDRPROCALC = 0
)
and PKSDOPDRREF=?
and SDOPDRPROCALC=false
and SDOPDRMND>=?
{code}
In the previous Hibernate 5.3.16, we got the following SQL statement, which works correctly:
{code:sql}
update
SDOPDR
set
FKSDOPDR_OPDRREF_MASTER=?
where
(
SDOPDRPROCALC = 0
)
and FKSDOPDR_OPDRREF_MASTER=?
and SDOPDRPROCALC=false
and SDOPDRMND>=?
{code}
Based on my investigation, this issue appears to be introduced by multiple changes:
[https://hibernate.atlassian.net/browse/ HHH-13875 |https : //hibernate.atlassian.net/browse/HHH-13875|smart-link] the addition of the {{isNull}} check inside {{dereferenceEntity}} causes that we don't get inside the {{isPropertyEmbeddedInJoinProperties}} method anymore, which is necessary. This would have been sufficient if we named our primary keys {{id}} instead of {{objectId}}. As part of our investigation we then downgraded to 5.4.12 which didn't contain this patch.
The combination of [ HHH-12842 ] and [ HHH-12775 ] prevents that the {{objectId}} path is properly registered inside {{AbstractPropertyMapping.initIdentifierPropertyPaths()}}.
As an attachment, you can find a number of traces of the AST of SQL, HBM, loggings of the mapping and the SQL statement itself.
I don't know what would be the best solution to solve this bug, I did however make a stripped down test case to reproduce this:
[^hibernate-test-case-templates.zip]
|
|
