The following sections indicate changes that are incompatible between OpenJPA 3.1.x releases and the 3.2.0 release.
                    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