quarkus: Hibernate dirty property false positives
Describe the bug
Beginning with Quarkus 2.14.1.Final and continuing through 2.15.2.Final, hibernate is detecting properties as dirty even if they have been set to the same value that is already in the entity.
eg
var myEntity = em.find(MyEntity.class, id); myEntity.setProperty(myEntity.getProperty());
Will result in an update sent to the db. Envers will actually NOT store an audit unless there is also an update timestamp that gets updated on persist such as one managed by @UpdateTimestamp. Envers is how I found this was happening since I do have such a timestamp implemented.
Turning hibernate logs up to 11, these are the only interesting entries I get.
2023-01-06 20:23:48,418 masergyball quarkus-run.jar[3876796] TRACE [org.hib.eve.int.DefaultFlushEntityEventListener] (executor-thread-0) Found dirty properties [[com.masergy.nms.nom.datamodel.BizNetMap#914587]] : [networkObjectClass, networkObjectSubClass, bizObj, node, service, netObj, datasource, grade]
2023-01-06 20:23:48,419 masergyball quarkus-run.jar[3876796] TRACE [org.hib.eve.int.DefaultFlushEntityEventListener] (executor-thread-0) Found dirty properties [[com.masergy.nms.nom.datamodel.BizNetMap#914587]] : [modifiedDatetime, networkObjectClass, networkObjectSubClass, bizObj, node, service, netObj, datasource, grade]
2.14.0.Final and 2.13.3.Final do not exhibit this behavior.
Expected behavior
If an entity property is set to the same value it already contained, the entity should not be marked dirty and updated in the database.
Actual behavior
Extra updates (and potentially envers audits) are sent to the database.
How to Reproduce?
No response
Output of uname -a or ver
Linux masergyball 6.0.15-300.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Dec 21 18:33:23 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
Output of java -version
openjdk version “11.0.17” 2022-10-18 OpenJDK Runtime Environment (Red_Hat-11.0.17.0.8-1.fc37) (build 11.0.17+8) OpenJDK 64-Bit Server VM (Red_Hat-11.0.17.0.8-1.fc37) (build 11.0.17+8, mixed mode, sharing)
GraalVM version (if different from Java)
No response
Quarkus version or git rev
2.14.1.Final - 2.15.2.Final
Build tool (ie. output of mvnw --version or gradlew --version)
Apache Maven 3.8.5 (3599d3414f046de2324203b78ddcf9b5e4388aa0) Maven home: /home/hcampbell/tools/maven Java version: 11.0.17, vendor: Red Hat, Inc., runtime: /usr/lib/jvm/java-11-openjdk-11.0.17.0.8-1.fc37.x86_64 Default locale: en_US, platform encoding: UTF-8 OS name: “linux”, version: “6.0.15-300.fc37.x86_64”, arch: “amd64”, family: “unix”
Additional information
No response
About this issue
- Original URL
- State: closed
- Created a year ago
- Comments: 15 (11 by maintainers)
Commits related to this issue
- Upgrade to Hibernate ORM 5.6.15.Final Fixes #30234 — committed to yrodiere/quarkus by yrodiere a year ago
- Upgrade to Hibernate ORM 5.6.15.Final Fixes #30234 — committed to yrodiere/quarkus by yrodiere a year ago
- Upgrade to Hibernate ORM 5.6.15.Final Fixes #30234 — committed to yrodiere/quarkus by yrodiere a year ago
- Upgrade to Hibernate ORM 5.6.15.Final Fixes #30234 (cherry picked from commit 41866da029df525903e4e49d121d2bda94e773dd) — committed to gsmet/quarkus by yrodiere a year ago
sure, I’m long done with the 5.6 changes and moved on to tuning ORM 6 - we could release a 5.6 anytime on the Hibernate side.
A bigger question is if there will actually be a Quarkus release to include the new version: with Quarkus 3.0 being the next version and it being expected to be based on Hibernate ORM 6, the 5.x upgrade would need to be done in a micro maintenance.
But let’s release ORM 5 either way, then at very least @Postremus has the option to override the version and we can see if there’s going to be an upgrade in Quarkus or not - plans are flexible and at least we’ll be ready for it. This could be useful for benchmarks too.
@yrodiere Not the op of this issue, but I can also reproduce problems with dirty checking since 2.14.1.Final (but not e.g. 2.13.3.Final).
Here is a reproducer: update-onetoone.zip
entity.setField(entity.getField());to test this problem.