Some NUMBER column types now get mapped to Boolean/Integer/Long instead of BigDecimal
Description
Attachments
- 12 Jul 2023, 11:35 AM
- 12 Jul 2023, 11:35 AM
relates to
Activity
Morgan PEYRE July 12, 2023 at 12:30 PM
Okay, so not a bug then. Thanks for your help and sorry I bothered you.
I can try and write a 6.0 migration guide PR if you think it would be useful.
Gavin King July 12, 2023 at 12:17 PM
Right. The change to the major version number 5->6 was made to indicate that this is a version of Hibernate which introduces breaking changes.
In principle this should be mentioned in the migration guide, but it might easily have slipped through.
Morgan PEYRE July 12, 2023 at 12:12 PM
To further clarify my problem: the last line of code in my previous comment throws a java.lang.ClassCastException with Hibernate 6
Morgan PEYRE July 12, 2023 at 12:05 PM
This change breaks some of our (admittedly fragile and suboptimal) query result parsing code, here’s an example:
Query query = em.createNativeQuery(sql.toString());
for (Object[] result : query.getResultList()) {
BigDecimal userId = (BigDecimal) result[15];If this backwards compatibility break is intentional, my apologies: this report can inded be closed (unless you think that a mention of the change in the migration guide is warranted).
Gavin King July 12, 2023 at 11:49 AM
P.S. If I recall correctly, this change was probably made so that Hibernate behaves the same on Oracle as on all other databases. That is, if we persist a field of type Long to a column, then running a native query on that column should return Long.
It seems that some type mappings have changed between Hibernate versions 5 and 6, is this intentional ? Here are some of the changes I’ve noticed when parsing NativeQuery results:
SQL Data type
Java type (Hibernate 5)
Java type (Hibernate 6)
NUMBER(19,0)
java.math.BigDecimal
java.lang.Long
NUMBER(1,0)
java.math.BigDecimal
java.lang.Integer or java.lang.Boolean