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.

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

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.

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.

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.

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