4. OpenJPA 3.2.0
Prev | Appendix 3. Migration Considerations |

## 4. OpenJPA 3.2.0

### 4.1. Incompatibilities

The following sections indicate changes that are incompatible between OpenJPA 3.1.x releases and the 3.2.0 release.

#### 4.1.1. SUM now always returns Double

We did fix the SUM operation to always return `Double` as requested by the spec. Previously we did return whatever Numeric the JDBC driver did serve, resulting in non portable code.

#### 4.1.2. Invalid Column Name Changes

We did review and update the list of invalid column names for most `DBDicationary`. The list of tested reserved words got enriched with previously forbidden column names to avoid backward incompatibility issues. The list can ge retrieved and configured via `DBDictionary.getInvalidColumnWordSet`

#### 4.1.3. MappingTool Behavior for HSQLDB

There have been 2 changes for Hypersonic (HSQLDB). We fixed a bug which did cause `long` fields getting mapped to `INTEGER` instead of `BIGINT`.

Java `double` fields previously got mapped to `NUMERIC` which does lack fraction digits. Thus the value `7.3425343` got truncated to `7`. We now map `double` fields in Entities to `DOUBLE` SQL column types.

#### 4.1.4. Respect TIMESTAMP precision in Oracle

Due to a bug we did hardcoded round at 3 digits precision. So we essentially only allowed millis, even on a TIMESTAMP(6) field. The new code does respect the second fractions and now defaults to 6. It should be compatible but it might behave very subtle different.

#### 4.1.5. Unary Operations return types

Before OpenJPA-3.2.0 Unary Operations like `MIN`, `MAX`, `SUM`, etc did return whatever type got returned by the JDBC driver. For certain column types this could also have been internal classes of that very JDBC driver. E.g. a `SELECT MAX(a.someLocalDateField) ..` might have returned an instance of types `com.oracle.jdbc....` or `com.microsoft.sqlserver...`, etc. We now use the respective `DBDictionary` to request the correct type from the `ResultSet`.

#### 4.1.6. PostgreSQL now supports setQueryTimeOut

PostgreSQL does now support client side setQueryTimeout. User might see this come alive and now return different when the situation occurs. This flag is automatically enabled if running against PostgreSQL 10 or later. It can also be configured manually via `DBDictionary.supportsQueryTimeout`

Prev | Up |
3. OpenJPA 2.3.0 | Home |