This is, in a sense, a combination of [HHH-7918|https://hibernate.atlassian.net/browse/HHH-7918] and [HHH-7948|https://hibernate.atlassian.net/browse/HHH-7948].
Steps:
# Tx1: Create {{ListRefEdEntity}}
# Tx2:
## Fetch {{ListRefEdEntity}} created at (1)
## Create and persist {{ListRefIngEntity}} associated with {{ListRefEdEntity}} fetched at (a)
## Change its data , associate with {{ListRefIngEntity}}
## Flush
## Change its data again
This will lead to 2nd revision of {{ListRefEdEntity}} with {{reffering_mod=false}}
See a [PR|https://github.com/hibernate/hibernate-orm/pull/5253] for with a test case.
We’ve caught this in {{5.4.32}}, but since test case fails on {{main}}, I’m assuming it affects every version since {{5.4.32}}
The way I see the problem is that by discarding both {{CollectionChangeWorkUnit}} and {{ModWorkUnit#data}} that contain calculated {{*_MOD}} flags, we are relying on the difference between {{oldState}} and {{newState}}, but debug shows that both states already contain added {{ListRefIngEntity}}, so comparing those gives us {{false}}.
From what I see, {{FlushEntityEvent}} is created with the entities state from {{PersistentContext}} and it differs from what it is in DB.
If we can’t rely on the difference between the states, I guess our only option is to store {{CollectionChangeWorkUnits}} inside {{ModWorkUnit}} and apply those right before execution. Am I wrong or missing something? |
|
