java.time types not usable for optimistic locking due to precision truncation
Description
is duplicated by
Activity
Show:

Christian Beikov September 29, 2023 at 10:25 AM
Yeah, that looks like a good workaround for ORM 5.

Stefan Fußenegger September 22, 2023 at 3:51 PM
for anyone stuck with an earlier version I believe using a custom type extending InstantType
is the best workaround:
Usage with @Type
(and optionally @TypeDef
):
Maybe someone would like to confirm that this is a viable workaround? (Note @Convert
won’t work as it’s not suitable for @Version
properties)
It was reported ( ) that java.time types use nanosecond precision when generating version values. When the database only supports e.g. microseconds,
OptimisticLockException
can occur due to the truncation in SQL. Ideally, we would now pass in the requested precision information into theorg.hibernate.type.descriptor.java.VersionJavaType
methods to solve this, though that would be a breaking change between 6.0.0.CR and Final.