OracleDialect: Changes in Number Type Mappings in Version 6

Hibernate ORM
1

Hello,

we were moving our app from Spring Boot 2.7 to 3 and noticed some changes in the type behavior in Hibernate 6.

We have some native queries with lists of Objects as result, so there are no definded types in entity classes.

// example
public List<List<Object>> findResults()
	{
		Query query = entityManager.createNativeQuery("select number1, number2 from table");

		return query.getResultList();
	}

With Hibernate 5 it would map all NUMBER types from the Oracle DB to BigDecimal.
Now with Hibernate 6 this has changed: It maps the type depending on the NUMBER column’s precition and scale:

  • NUMBER(1,0) maps to Boolean instead of BigDecimal
  • NUMBER maps to Float instead of BigDecimal

Is this intended?
This seems to contradict what JDBC does and also what the Hibernate documentation says ( Hibernate ORM 6.1.7.Final User Guide (jboss.org))

This was testet with Hibernate 6.1.7 and 6.2.0. As a workaround we have now overriden the OracleDialect class.

2

I don’t know what you tested, but the latest OracleDialect in Hibernate ORM 6.2.0.Final does not map NUMBER(1,0) to Boolean anymore. The mapping to FLOAT is a special case that only happens if JDBC reports a scale of -127, which seems to be a special value that indicates float semantics.

3

Thank’s for your reply beikov.

You are correct: with 6.2.0.Final the mapping to Boolean has gone. And we actually witnessed the strange -127 scale.

But there are still cases where NUMBER types wouldn’t map to BigDecimal:

e.g. NUMBER(10,0) would map to Integer.
I’m just wondering if this is correct while JDBC is mapping all NUMBER types to BigDecimal?

4

The JPA specification doesn’t say anything about how we should interpret native query results when no result set mapping is given. Usually, we try to follow map native query results similar to how we would generate a schema though. Since we generate NUMBER(10,0) for persistent attributes of type Integer, we try to map that back to Integer then also.

5

Thank’s for the clarification.

6

Not quite true. This is actually a bug. Refer to:
https://hibernate.atlassian.net/browse/HHH-16650

2 Likes