diff --git a/openjpa-project/src/doc/manual/migration_considerations.xml b/openjpa-project/src/doc/manual/migration_considerations.xml index 9c39a1491..02ee86ec9 100644 --- a/openjpa-project/src/doc/manual/migration_considerations.xml +++ b/openjpa-project/src/doc/manual/migration_considerations.xml @@ -458,24 +458,24 @@ . -
+
Cascade persist behavior - - In previous releases, OpenJPA would check the database for the - existence of the related Entity before persisting the relationship to - that Entity. This resulted in an extra Select being sent to the - database. In 2.2.0, code was added so that when cascading a persist to - a related Entity without persistence state, the persist (insert) will - happen without first checking the database. This may result in an - EntityExistsException if the related Entity already exists in the - database. To revert this behavior to the previous release, set the - value of the openjpa.Compatibility - property CheckDatabaseForCascadePersistToDetachedEntity - to true. - + + In previous releases, OpenJPA would check the database for the + existence of the related Entity before persisting the relationship to + that Entity. This resulted in an extra Select being sent to the + database. In 2.2.0, code was added so that when cascading a persist to + a related Entity without persistence state, the persist (insert) will + happen without first checking the database. This may result in an + EntityExistsException if the related Entity already exists in the + database. To revert this behavior to the previous release, set the + value of the openjpa.Compatibility + property CheckDatabaseForCascadePersistToDetachedEntity + to true. +
@@ -578,4 +578,77 @@ </section> </section> </section> + <section id="jpa_3.2"> + <title>OpenJPA 3.2.0 +
+ Incompatibilities + + The following sections indicate changes that are incompatible + between OpenJPA 3.1.x releases and the 3.2.0 release. + +
+ 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. + +
+
+ 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 + +
+
+ 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. + +
+
+ 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. + +
+
+ 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. + +
+
+ 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 + +
+
+
+