[hibernate-commits] [hibernate/hibernate-orm] 434e45: HHH-20661 Return shared DateJavaType instances per...
Branch: refs/heads/main
Home: https://github.com/hibernate/hibernate-orm
Commit: 434e45815dc366c09648c854eecf6cc6487e470d
https://github.com/hibernate/hibernate-orm/commit/434e45815dc366c09648c85...
Author: Develop-KIM <kimdonghwan913(a)gmail.com>
Date: 2026-07-14 (Tue, 14 Jul 2026)
Changed paths:
M hibernate-core/src/main/java/org/hibernate/type/descriptor/java/DateJavaType.java
A
hibernate-core/src/test/java/org/hibernate/orm/test/query/hql/UnionSameJavaTypeDifferentPathTest.java
Log Message:
-----------
HHH-20661 Return shared DateJavaType instances per temporal precision
DateJavaType#resolveTypeForPrecision created a new DateJavaType on every
call, so the same java.util.Date reached through different attribute paths
(e.g. an entity field vs. one inherited from a @MappedSuperclass) resolved
to distinct JavaType instances. A union of two such columns was then
rejected by SqmQueryGroup's identity comparison with "Select items of the
same index must have the same java type across all query parts", even
though the equivalent Criteria query worked.
Follow the pattern used by the other temporal JavaTypes: override
forDatePrecision/forTimePrecision/forTimestampPrecision to return shared
per-precision instances instead of allocating a new one. Resolving the
same precision now yields the same instance, so the existing identity
comparison keeps working and genuinely different types are still rejected.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply(a)anthropic.com>
To unsubscribe from these emails, change your notification settings at
https://github.com/hibernate/hibernate-orm/settings/notifications