| <?xml version="1.0" encoding="UTF-8"?> |
| <!-- |
| Licensed to the Apache Software Foundation (ASF) under one |
| or more contributor license agreements. See the NOTICE file |
| distributed with this work for additional information |
| regarding copyright ownership. The ASF licenses this file |
| to you under the Apache License, Version 2.0 (the |
| "License"); you may not use this file except in compliance |
| with the License. You may obtain a copy of the License at |
| |
| http://www.apache.org/licenses/LICENSE-2.0 |
| |
| Unless required by applicable law or agreed to in writing, |
| software distributed under the License is distributed on an |
| "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY |
| KIND, either express or implied. See the License for the |
| specific language governing permissions and limitations |
| under the License. |
| --> |
| <appendix id="migration_considerations" role="non-normative"> |
| <title> |
| Migration Considerations |
| </title> |
| <section id="jpa_2.0"> |
| <title> |
| OpenJPA 2.0.0 |
| </title> |
| <section id="jpa_2.0_incompatibilities"> |
| <title> |
| Incompatibilities |
| </title> |
| <!-- See OPENJPA-1208 for details. --> |
| <para> |
| The following sections indicate changes that are incompatible |
| between OpenJPA 1.x.x releases and the 2.0 release. Some may |
| require application changes. Others can be remedied through the |
| use of compatibility options. If your application uses a |
| version 1.0 persistence.xml, compatibility options will be set |
| appropriately to maintain backward compatibility. OpenJPA 2.0 |
| applications using a version 2.0 persistence.xml and requiring |
| OpenJPA 1.x.x compatibility may need to configure the |
| appropriate compatibility options to get the desired behavior. |
| </para> |
| <section id="getProperties"> |
| <title> |
| getProperties() |
| </title> |
| <!-- See OPENJPA-849 for details. --> |
| <para> |
| The OpenJPAEntityManagerFactory interface getProperties() |
| method was changed to return a Map instead of a |
| Properties object. This change was made in order to |
| support the getProperties() method defined in the |
| JPA 2.0 specification. |
| </para> |
| </section> |
| <section id="migration_detach_behavior"> |
| <title> |
| Detach Behavior |
| </title> |
| <!-- See OPENJPA-1215 for details. --> |
| <para> |
| The detach behavior has changed in several ways: |
| <itemizedlist> |
| <listitem> |
| <para> |
| In the 1.x.x release, managed entities |
| were flushed to the database as part of the |
| detach operation. This is no longer done in |
| 2.0. |
| </para> |
| </listitem> |
| <listitem> |
| <para> |
| In the 1.x.x release, entities were copied |
| and returned. In 2.0, for those methods |
| that have return values, the original |
| entities are returned. |
| </para> |
| </listitem> |
| <listitem> |
| <para> |
| In the 1.x.x release, managed entities still |
| exist in the persistent context. In 2.0, |
| they are removed. |
| </para> |
| </listitem> |
| <listitem> |
| <para> |
| In the 1.x.x release, the detach operation |
| is recursively cascaded to all referenced |
| entities. In 2.0, the detach operation is |
| only cascaded to those entities for which |
| Cascade=detach has been specified. |
| </para> |
| </listitem> |
| </itemizedlist> |
| </para> |
| <para> |
| Applications that use a 1.0 persistence.xml will |
| automatically maintain OpenJPA 1.x.x behavior. It is |
| possible for a version 2.0 application to revert back to |
| the 1.x.x behavior for some of these items by setting the |
| openjpa.Compatibility property as follows: |
| <simplelist> |
| <member>CopyOnDetach=true</member> |
| <member>FlushBeforeDetach=true</member> |
| <member>CascadeWithDetach=true</member> |
| </simplelist> |
| </para> |
| <para> |
| In addition, a new method has been provided on the |
| <ulink url="../../apidocs/org/apache/openjpa/persistence/OpenJPAEntityManager.html"> |
| <classname>OpenJPAEntityManager</classname></ulink> |
| interface to return a copy of the entity: |
| <programlisting> |
| public <T> T detachCopy(T pc): |
| </programlisting> |
| </para> |
| </section> |
| <section id="private_persistent_properties"> |
| <title> |
| Use of private persistent properties |
| </title> |
| <!-- See OPENJPA-1176 for details. --> |
| <para> |
| In 1.x.x releases of OpenJPA, if property access was used, |
| private properties were considered persistent. This is |
| contrary to the JPA specification, which states that |
| persistent properties must be public or protected. In |
| OpenJPA 2.0 and later, private properties will not be |
| persistent by default. |
| </para> |
| <para> |
| Applications that use a 1.0 persistence.xml will |
| automatically maintain OpenJPA 1.x.x behavior. It is |
| possible for a version 2.0 application to revert back to |
| the 1.x.x behavior by setting the value of the |
| <literal>openjpa.Compatibility</literal> |
| property <literal>PrivatePersistentProperties</literal> to |
| <literal>true</literal>. If compile time enhancement is |
| used, this property must be specified at the time of |
| enhancement and at runtime. |
| </para> |
| </section> |
| <section id="setParameter"> |
| <title> |
| Query.setParameter() |
| </title> |
| <!-- See OPENJPA-1213 for details. --> |
| <para> |
| The Query interface setParameter() method behavior has |
| changed to throw an IllegalArgumentException (as required |
| by the JPA specification) if more parameter substitutions |
| are supplied than defined in the createQuery(), |
| createNamedQuery(), or createNativeQuery() invocation. |
| OpenJPA 1.2.x and prior versions silently ignored these |
| extraneous parameter substitutions and allowed the Query |
| to be processed. |
| </para> |
| </section> |
| <section id="serialization"> |
| <title> |
| Serialization of Entities |
| </title> |
| <!-- See OPENJPA-1097 and OPENJPA-1597 for details. --> |
| <para> |
| In 1.x.x releases of OpenJPA, when an entity was serialized |
| after calling EntityManager.find(), detach() or detachAll() |
| then all <xref linkend="ref_guide_pc_scos_proxy"/> |
| references were removed as expected, but when the same |
| entity instance was serialized after calling |
| EntityManager.clear() the proxy classes were not removed. |
| </para> |
| <para> |
| This has two side-effects: |
| when entities are remoted across JVM boundaries (RPC) |
| or deserialized the OpenJPA runtime must be available |
| on the classpath (both client and server containers); |
| when entities are deserialized the OpenJPA runtime must |
| be the exact same revision as used to serialize the |
| entities due to the proxy classes using dynamically |
| generated serialVersionUID values. |
| </para> |
| <para> |
| Starting with OpenJPA 2.0, this behavior has been |
| modified, so that by default all proxies will be removed |
| during serialization. See |
| <xref linkend="ref_guide_pc_scos_proxy_serial"/> |
| on how the behavior changes based on the |
| <literal>DetachedStateField</literal> setting along with |
| <xref linkend="ref_guide_detach_state"/> |
| for more details on how to override the default |
| <literal>DetachedStateField</literal> setting. |
| </para> |
| <para> |
| Applications that use a 1.0 persistence.xml will |
| automatically maintain the old behavior. It is |
| possible for a version 2.0 application to revert back to |
| the prior 1.x.x behavior by setting the following |
| openjpa.Compatibility property as follows: |
| <simplelist> |
| <member>IgnoreDetachedStateFieldForProxySerialization=true</member> |
| </simplelist> |
| </para> |
| </section> |
| <section id="QuerySQLCache"> |
| <title> |
| openjpa.jdbc.QuerySQLCache |
| </title> |
| <!-- See OPENJPA-1179 for details. --> |
| <para> |
| In prior 1.x.x releases, the openjpa.jdbc.QuerySQLCache |
| configuration property for Prepared SQL Cache accepted |
| value <literal>all</literal> to never drop items from the |
| cache, but this option is no longer supported and will cause |
| a PersistenceException with a root cause of a ParseException |
| to be thrown. See |
| <xref linkend="ref_guide_cache_querysql"/> |
| for details on the available configuration values. |
| </para> |
| </section> |
| </section> |
| <section id="Disabling AutoOff Collection Tracking"> |
| <title> |
| Disabling AutoOff Collection Tracking |
| </title> |
| <!-- See OPENJPA-1223 and OPENJPA-1163 for details. --> |
| <para> |
| The default behavior of OpenJPA in tracking collections is that |
| if the number of modifications to the collection exceeds the |
| current number of elements in collection then OpenJPA will |
| disable tracking the collections. OpenJPA 2.0 added a compatibility |
| property to disable turning off the collection tracking. |
| </para> |
| <para> |
| The behavior of Auto disabling of collection tracking can be |
| avoided by setting the value of the |
| <literal>openjpa.Compatibility</literal> property |
| <literal>autoOff</literal> to <literal>false</literal>. |
| The default behavior of auto disabling the collection tracking |
| is not changed. But when the above property is set then the |
| collection tracking will not be disabled automatically. |
| </para> |
| </section> |
| <section id="internal_differences"> |
| <title> |
| Internal Behavioral Differences |
| </title> |
| <para> |
| The following sections indicate internal changes between |
| OpenJPA 1.x.x releases and the 2.0 release. As these are |
| internal implementation specific behaviors not covered by |
| the JPA specification, no changes should be required for |
| applications that did not use or depend upon OpenJPA specific |
| APIs or behavior. |
| </para> |
| |
| <section id="prePostUpdate"> |
| <title> |
| PreUpdate/PostUpdate Life Cycle Callbacks |
| </title> |
| <!-- See OPENJPA-1182 for details. --> |
| <para> |
| If an entity was updated between the persist() |
| and commit() operations in OpenJPA 1.x, then |
| any PreUpdate and PostUpdate life cycle callback |
| methods would be executed. Starting in OpenJPA |
| 1.3 and 2.0, these callbacks will not get executed. |
| </para> |
| <para> |
| The JPA 2.0 specification section on "Semantics |
| of the Life Cycle Callback Methods for Entities" |
| has been updated to include a Note that the |
| callback behavior for updating an entity after |
| the persist operation is implementation specific |
| and should not be relied upon. |
| </para> |
| </section> |
| <section id="createemf"> |
| <title> |
| createEntityManagerFactory Exceptions |
| </title> |
| <!-- See OPENJPA-1203 for details. --> |
| <para> |
| The JPA 2.0 specification section on |
| "Bootstrapping in Java SE Environments" states |
| that persistence providers must return null |
| if they are not a qualified provider for the |
| given persistence unit. |
| </para> |
| <para> |
| However, OpenJPA may throw a RuntimeException |
| if an error occurs while trying to create a |
| qualified persistence unit, like for invalid |
| openjpa.* specific configuration settings or |
| for schema validation failures. |
| </para> |
| <para> |
| If the Apache Geronimo JPA 2.0 Spec APIs are |
| used, then any exceptions returned by a |
| persistence provider will be wrapped within |
| a PersistenceException. When the JPA 2.0 API |
| reference implementation is used, any |
| RuntimeExceptions will be returned to the |
| calling application without being wrapped. |
| Other JPA 2.0 API and implementation providers |
| or versions may behave differently. |
| </para> |
| </section> |
| <section id="querycache"> |
| <title> |
| openjpa.QueryCache default |
| </title> |
| <!-- See OPENJPA-1469 and sub-tasks for details. --> |
| <para> |
| In previous releases, the default value for the |
| openjpa.QueryCache property was <literal>true</literal> |
| when the openjpa.DataCache was enabled. Depending on |
| application characteristics, this default QueryCache |
| enablement actually could negate much of the potential |
| gains achieved by using the DataCache. Thus, the default |
| value for the openjpa.QueryCache property is now |
| <emphasis><literal>false</literal></emphasis>. |
| </para> |
| <para> |
| To re-enable the default QueryCache behavior, you need to |
| include the following property in your persistence.xml |
| configuration. |
| <programlisting> |
| <property name="openjpa.QueryCache" value="true"/> |
| </programlisting> |
| </para> |
| <para> |
| If your configuration had previously enabled the QueryCache |
| explicitly, then you might have to include the |
| <literal>true</literal> value into your configuration |
| (if you relied on the previous default). Otherwise, your |
| current QueryCache enablement will continue to work. |
| <programlisting> |
| <property name="openjpa.QueryCache" value="true(CacheSize=1000, SoftReferenceSize=100)"/> |
| </programlisting> |
| </para> |
| </section> |
| </section> |
| </section> |
| <section id="jpa_2.2"> |
| <title> |
| OpenJPA 2.2.0 |
| </title> |
| <section id="jpa_2.2_incompatibilities"> |
| <title>Incompatibilities</title> |
| <para> |
| The following sections indicate changes that are incompatible |
| between OpenJPA 2.1.x releases and the 2.2.0 release. |
| </para> |
| <section id="jpa_2.2_allocationSize"> |
| <title> |
| allocationSize Property of Sequence Generator |
| </title> |
| <!-- See OPENJPA-1376 for details. --> |
| <para> |
| In previous releases, specifying the <literal>allocationSize</literal> property of |
| <link linkend="jpa_overview_mapping_sequence_seqgen">sequence generator</link> |
| affected only sequence definition in the database. During |
| schema creation, the <literal>INCREMENT BY</literal> clause of |
| <literal>CREATE SEQUENCE</literal> statement always |
| had a value of 1 and on DB2, Oracle and PostgreSQL databases a <literal>CACHE</literal> clause |
| was added with the value of <literal>allocationSize</literal> property. Such a statement caused |
| sequence values being cached in the database. Starting with OpenJPA 2.2.0, |
| sequence values are cached in the jvm memory and the <literal>allocationSize</literal> |
| property determines size of that cache. The <literal>CACHE</literal> clause is no longer used, |
| instead the <literal>INCREMENT BY</literal> clause gets its value equal to the |
| <literal>allocationSize</literal> property. Such a strategy reduces the number of database roundtrips |
| required for retrieving sequence values considerably. |
| </para> |
| <para> |
| In order for the existing applications to work with OpenJPA |
| 2.2.0, you have to manually recreate or redefine sequences, specifying |
| the correct <literal>INCREMENT BY</literal> value and, possibly, correct initial sequence value. |
| Note that the default value of the <literal>allocationSize</literal> property is 50 and that |
| value is used if the property is not specified. |
| </para> |
| <para> |
| The requirement for sequence modification applies to all databases that support sequences, regardless of |
| the <literal>CACHE</literal> clause being supported. The only exception is Firebird database - |
| since with this database the increment step is determined during sequence |
| value fetch, no migration activity is needed. |
| </para> |
| <para> |
| To maintain the old behavior of sequence generator in OpenJPA 2.2.0, you can: |
| <itemizedlist> |
| <listitem> |
| <para> |
| Set the <literal>allocationSize</literal> property value to 1. |
| </para> |
| </listitem> |
| <listitem> |
| <para> |
| Additionally, if the <literal>CACHE</literal> clause has to be emitted in sequence definition, |
| this can be accomplished by overriding the |
| <ulink url="../../apidocs/org/apache/openjpa/jdbc/sql/DBDictionary.html#getCreateSequenceSQL(org.apache.openjpa.jdbc.schema.Sequence)"> |
| <methodname>DBDictionary.getCreateSequenceSQL</methodname></ulink> method. |
| </para> |
| </listitem> |
| </itemizedlist> |
| </para> |
| </section> |
| <section id="jpa_2.2_metamodelArrays"> |
| <title> |
| MetaModel Attributes for Arrays |
| </title> |
| <!-- See OPENJPA-2025 for details. --> |
| <para> |
| In previous releases OpenJPA's MetaModel implementation generated a ListAttribute for every array. This behavior is correct if the array |
| is annotated as a PersistentCollection, but not correct for un-annotated arrays (e.g. byte[], char[]). In OpenJPA 2.2.0 this behavior was corrected |
| so that arrays which are not stored as PersistentCollections will use a SingularAttribute instead of a ListAttribute. |
| </para> |
| <para> |
| If your application uses the MetaModel API and your entities contain arrays of any of the following types: byte[], Byte[], char[], Character[] and |
| do not use the @PersistentCollection annotation with those fields you will need to update your application to use OpenJPA 2.2.0. |
| </para> |
| <para> In order for the existing applications to work with OpenJPA you may: |
| <itemizedlist> |
| <listitem> |
| <para> Regenerate the canonical metamodel classes</para> |
| </listitem> |
| <listitem> |
| <para> Set the Compatibility property <literal>UseListAttributeForArrays</literal> to <literal>true</literal> in persistence.xml |
| <programlisting> <property name="openjpa.Compatibility" value="UseListAttributeForArrays=true"/></programlisting> |
| </para> |
| </listitem> |
| </itemizedlist> |
| </para> |
| </section> |
| <section id="jpa_2.2_SupportsSetClob"> |
| <title> |
| supportsSetClob Property. |
| </title> |
| <!-- See OPENJPA-1691 for details. --> |
| <para> |
| In OpenJPA 2.2.0, code was added to allow the setting of CLOB or XML data larger than 4000 bytes. This functionality |
| was eventually back ported to previous releases, and enabled by the <literal>supportsSetClob</literal> property on the OracleDictionary. Setting this property |
| has no effect in 2.2.0 and later releases and any occurrence of it should be removed. |
| </para> |
| </section> |
| <section id="jpa_2.2_UseNativeSequenceCache"> |
| <title> |
| useNativeSequenceCache Property. |
| </title> |
| <!-- See OPENJPA-1376 for details. --> |
| <para> |
| In OpenJPA 2.2.0, code was added which changed the way sequences were generated, please see |
| <xref linkend="jpa_2.2_allocationSize"/> for details. This functionality was eventually back ported |
| to previous releases, and enabled by the <literal>useNativeSequenceCache</literal> property on the DBDictionary. Setting this property |
| has no effect in 2.2.0 and later releases and any occurrence of it should be removed. If previous behavior is |
| desired (i.e. <literal>useNativeSequenceCache=true</literal>), please see the details described in section |
| <xref linkend="jpa_2.2_allocationSize"/>. |
| </para> |
| </section> |
| <section id="jpa_2.2_cascadePersist"> |
| <title> |
| Cascade persist behavior |
| </title> |
| <!-- See OPENJPA-1986 for details. --> |
| <para> |
| 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 <literal>openjpa.Compatibility</literal> |
| property <literal>CheckDatabaseForCascadePersistToDetachedEntity</literal> |
| to <literal>true</literal>. |
| </para> |
| </section> |
| <section id="jpa_2.2_LifecycleEventManager"> |
| <title> |
| Life Cycle Event Manager Callback Behavior |
| </title> |
| <!-- See OPENJPA-2163 for details. --> |
| <para> |
| Life cycle event manager is used to manage entity's life cycle event callback. |
| In previous releases, Life cycle event manager is scoped to EntityManagerFactory. |
| This means listeners registered to an individual EntityManager may get life cycle |
| event callbacks for entity that it does not manage. |
| </para> |
| <para> |
| From 2.2.1 release, the default callback behavior of the life cycle event manager |
| is changed to scope to each EntityManager. |
| To revert this behavior to the previous release, set the |
| value of the <literal>openjpa.Compatibility</literal> |
| property <literal>SingletonLifecycleEventManager</literal> |
| to <literal>true</literal>. |
| </para> |
| </section> |
| <section id="jpa_2.2_sharedCacheMode"> |
| <title> |
| shared-cache-mode Property |
| </title> |
| <!-- See OPENJPA-1532 for details. --> |
| <para> |
| In the previous release, when the shared-cache-mode is enabled and the DataCache property is not set |
| or set to false, there will be no data caching. |
| </para> |
| <para> |
| From 2.2.2 release, the caching will be turned on if the shared-cache-mode is enabled. Please see the |
| details described in section <xref linkend="ref_guide_shared_cache_mode_integration"/>. |
| </para> |
| </section> |
| </section> |
| </section> |
| <section id="jpa_2.3"> |
| <title> |
| OpenJPA 2.3.0 |
| </title> |
| <section id="jpa_2.3_incompatibilities"> |
| <title>Incompatibilities</title> |
| <para> |
| The following sections indicate changes that are incompatible |
| between OpenJPA 2.2.x releases and the 2.3.0 release. |
| </para> |
| <section id="jpa_2.3_MappingTool"> |
| <title> |
| MappingTool Behavior for DB2 and Derby |
| </title> |
| <para> |
| In previous releases, the MappingTool mapped <literal>java.math.BigDecimal</literal> fields to the database type |
| DOUBLE, and as such, ignored <literal>column</literal> and <literal>precision</literal> values that might have been specified via the |
| <literal>javax.persistence.Column</literal> annotation. |
| </para> |
| <para> |
| From the 2.3.0 release, <literal>java.math.BigDecimal</literal> fields are now mapped to the database type DECIMAL |
| and it is very likely that you will need to specify <literal>column</literal> and <literal>precision</literal> via |
| the <literal>javax.persistence.Column</literal> annotation. |
| </para> |
| </section> |
| <section id="jpa_2.3_RequiresSearchStringEscapeForLike"> |
| <title> |
| RequiresSearchStringEscapeForLike DBDictionary Property |
| </title> |
| <!-- See OPENJPA-2282 for details. --> |
| <para> |
| In previous releases, the default value for the property RequiresSearchStringEscapeForLike is true and caused the |
| unexpected escape clause appended to the SQL statement. |
| For example, user created a named query like this: |
| <programlisting> SELECT o.computerName FROM CompUser o WHERE o.name LIKE ?</programlisting> |
| At run time the following query is generated: |
| <programlisting> SELECT t0.computerName FROM CompUser t0 WHERE (t0.name LIKE ? ESCAPE '\')</programlisting> |
| ESCAPE '\' shouldn't be appended to the query. |
| </para> |
| <para> |
| From the 2.3.0 release, RequiresSearchStringEscapeForLike property is set to false by default. You can configure |
| RequiresSearchStringEscapeForLike property to be true if the old behavior is desired. |
| </para> |
| </section> |
| <section id="ReturnNullOnEmptyAggregateResult"> |
| <title> |
| Return value of aggregate functions in SELECT clause |
| </title> |
| <!-- See OPENJPA-1794 for details. --> |
| <para> |
| The JPA specification states "If SUM, AVG, MAX, or MIN is used, and there are no values to which the aggregate function can be |
| applied, the result of the aggregate function is NULL." Prior to this update, OpenJPA incorrectly returned 0 for SUM, AVG, MIN, |
| and MAX when a state field being aggregated is numeric. This behavior affects both JPQL and Criteria queries. With this update, |
| OpenJPA will return a null result value for these aggregate functions when a query returns no result. |
| </para> |
| <para> |
| To re-enable the prior behavior, you need to set the following persistence property in your persistence.xml or when |
| creating an EntityManagerFactory. |
| <programlisting> |
| <property name="openjpa.Compatibility" value="ReturnNullOnAggregateResult=false"/> |
| </programlisting> |
| </para> |
| </section> |
| </section> |
| </section> |
| <section id="jpa_3.2"> |
| <title>OpenJPA 3.2.0</title> |
| <section id="jpa_3.2_incompatibilities"> |
| <title>Incompatibilities</title> |
| <para> |
| The following sections indicate changes that are incompatible |
| between OpenJPA 3.1.x releases and the 3.2.0 release. |
| </para> |
| <section id="jpa_3.2_SumDouble"> |
| <title>SUM now always returns Double</title> |
| <para> |
| We did fix the SUM operation to always return <classname>Double</classname> as requested by the spec. |
| Previously we did return whatever Numeric the JDBC driver did serve, resulting in non portable code. |
| </para> |
| </section> |
| <section id="jpa_3.2_InvalidColumnNames"> |
| <title>Invalid Column Name Changes</title> |
| <para> |
| We did review and update the list of invalid column names for most <classname>DBDicationary</classname>. |
| 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 |
| <ulink url="../../apidocs/org/apache/openjpa/jdbc/sql/DBDictionary.html#getInvalidColumnWordSet()"> |
| <methodname>DBDictionary.getInvalidColumnWordSet</methodname></ulink> |
| </para> |
| </section> |
| <section id="jpa_3.2_HsqlMappingTool"> |
| <title>MappingTool Behavior for HSQLDB</title> |
| <para> |
| There have been 2 changes for Hypersonic (HSQLDB). |
| We fixed a bug which did cause <classname>long</classname> fields getting mapped to <literal>INTEGER</literal> |
| instead of <literal>BIGINT</literal>. |
| </para> |
| <para> |
| Java <classname>double</classname> fields previously got mapped to <literal>NUMERIC</literal> which |
| does lack fraction digits. Thus the value <literal>7.3425343</literal> got truncated to <literal>7</literal>. |
| We now map <classname>double</classname> fields in Entities to <literal>DOUBLE</literal> SQL column types. |
| </para> |
| </section> |
| <section id="jpa_3.2_OracleTimestampPrecision"> |
| <title>Respect TIMESTAMP precision in Oracle</title> |
| <para> |
| 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. |
| </para> |
| </section> |
| <section id="jpa_3.2_UnaryOps"> |
| <title>Unary Operations return types</title> |
| <para> |
| Before OpenJPA-3.2.0 Unary Operations like <literal>MIN</literal>, <literal>MAX</literal>, <literal>SUM</literal>, 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 <literal>SELECT MAX(a.someLocalDateField) ..</literal> might have returned |
| an instance of types <classname>com.oracle.jdbc....</classname> or <literal>com.microsoft.sqlserver...</literal>, etc. |
| We now use the respective <ulink url="../../apidocs/org/apache/openjpa/jdbc/sql/DBDictionary.html"> |
| <methodname>DBDictionary</methodname></ulink> to request the correct type from the <classname>ResultSet</classname>. |
| </para> |
| </section> |
| <section id="jpa_3.2_PostgreSqlQueryTimeout"> |
| <title>PostgreSQL now supports setQueryTimeOut</title> |
| <para> |
| 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 |
| <ulink url="../../apidocs/org/apache/openjpa/jdbc/sql/DBDictionary.html#supportsQueryTimeout"> |
| <fieldname>DBDictionary.supportsQueryTimeout</fieldname></ulink> |
| </para> |
| </section> |
| </section> |
| </section> |
| |
| </appendix> |
