The following sections indicate changes that are incompatible between OpenJPA 2.1.x releases and the 2.2.0 release.
In previous releases, specifying the allocationSize
property of
sequence generator
affected only sequence definition in the database. During
schema creation, the INCREMENT BY
clause of
CREATE SEQUENCE
statement always
had a value of 1 and on DB2, Oracle and PostgreSQL databases a CACHE
clause
was added with the value of allocationSize
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 allocationSize
property determines size of that cache. The CACHE
clause is no longer used,
instead the INCREMENT BY
clause gets its value equal to the
allocationSize
property. Such a strategy reduces the number of database roundtrips
required for retrieving sequence values considerably.
In order for the existing applications to work with OpenJPA
2.2.0, you have to manually recreate or redefine sequences, specifying
the correct INCREMENT BY
value and, possibly, correct initial sequence value.
Note that the default value of the allocationSize
property is 50 and that
value is used if the property is not specified.
The requirement for sequence modification applies to all databases that support sequences, regardless of
the CACHE
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.
To maintain the old behavior of sequence generator in OpenJPA 2.2.0, you can:
Set the allocationSize
property value to 1.
Additionally, if the CACHE
clause has to be emitted in sequence definition,
this can be accomplished by overriding the
DBDictionary.getCreateSequenceSQL
method.
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.
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.
In order for the existing applications to work with OpenJPA you may:
Regenerate the canonical metamodel classes
Set the Compatibility property UseListAttributeForArrays
to true
in persistence.xml
<property name="openjpa.Compatibility" value="UseListAttributeForArrays=true"/>
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 supportsSetClob
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.
In OpenJPA 2.2.0, code was added which changed the way sequences were generated, please see
Section 2.1.1, “
allocationSize Property of Sequence Generator
” for details. This functionality was eventually back ported
to previous releases, and enabled by the useNativeSequenceCache
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. useNativeSequenceCache=true
), please see the details described in section
Section 2.1.1, “
allocationSize Property of Sequence Generator
”.
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
.
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.
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 openjpa.Compatibility
property SingletonLifecycleEventManager
to true
.