AccessPlatform : Migration between versions
This version of DataNucleus AccessPlatform builds on the 3.1 releases.
As this is a minor release cycle some internal APIs are changed from 3.1.
All releases are checked regularly against the JDO/JPA TCKs, meaning that DataNucleus is
always stable in terms of functionality.
Occasionally, due to unknown bugs, or due to new functionality being introduced we need to
change some aspects of DataNucleus. As a result sometimes users will have to make some
changes to move between versions of DataNucleus. We aim to keep this to a minimum.
Migration from 3.2.6 to 3.2.7
Migrating from AccessPlatform 3.2.6 to 3.2.7 will require the following changes
- datanucleus-googlecollections plugin is now renamed to datanucleus-guava
Migration from 3.2.2 to 3.2.3
Migrating from AccessPlatform 3.2.2 to 3.2.3 will require the following changes
- The persistence property datanucleus.metadata.validate is renamed to
datanucleus.metadata.xml.validate to better describe its usage. The original
name is still supported but you are advised to move to this new naming as the old one
can be removed in a future release.
Migration from 3.2.1 to 3.2.2
Migrating from AccessPlatform 3.2.1 to 3.2.2 will require no changes.
Migration from 3.2.0.RELEASE to 3.2.1
Migrating from AccessPlatform 3.2.0.RELEASE to 3.2.1 will require the following changes
- The persistence property datanucleus.attachSameDatastore defaults to true
with datanucleus-core version 3.2.1 and later.
Set it to false if you require replicating objects into other datastores
- The JDOQL method Date.getDay is now deprecated and Date.getDate should be
used instead (day of the month). Date.getDay is likely to be converted to return
the day of the week in a later release, so fixing any use of this now makes sense
- PreparedStatement pooling is turned now turned OFF by default due to the fact that
DBCP has a bug where it isn't closing ResultSets correctly when this is enabled.
Migration from 3.2.0.M4 to 3.2.0.RELEASE
Migrating from AccessPlatform 3.2.0.M4 to 3.2.0.RELEASE should require no changes.
Migration from 3.2.0.M3 to 3.2.0.M4
Migrating from AccessPlatform 3.2.0.M3 to 3.2.0.M4 will require the following changes.
- The RDBMS persistence property datanucleus.rdbms.sqlParamValuesInBrackets is now
removed, and replaced by datanucleus.rdbms.statementLogging (see the docs)
- The persistence property datanucleus.rdbms.useUpdateLock is now removed (was
deprecated many releases back). Use standard JDO/JPA locking mechanisms instead.
- Any user-defined RDBMS mapping plugins will need updating to match some minor type
changes to the "datanucleus-rdbms" plugin API.
Migration from 3.2.0.M2 to 3.2.0.M3
Migrating from AccessPlatform 3.2.0.M2 to 3.2.0.M3 will require no changes.
Migration from 3.2.0.M1 to 3.2.0.M2
Migrating from AccessPlatform 3.2.0.M1 to 3.2.0.M2 will require the following changes.
- The Maven plugin has been renamed to datanucleus-maven-plugin from
maven-datanucleus-plugin to match Maven3 naming policies.
- You no longer require to include asm.jar since version 4.1 of ASM is now repackaged
- Added persistence property "datanucleus.useImplementationCreator" to allow turning off
the persistent interface implementation creator.
- All java type mappings used by the RDBMS plugin are now moved
from org.datanucleus.store.mapped.mapping in the core plugin,
to org.datanucleus.store.rdbms.mapping.java in the RDBMS plugin. Related
classes only for "mapped" datastores are also now in the RDBMS plugin
Migration from 3.1.x to 3.2.0.M1
Migrating from AccessPlatform 3.1 to 3.2.0.M1 will require the following changes.
- The Enhancer plugin is now merged into "datanucleus-core".
Note also that the "pre-compilation" enhancement process is now discontinued.
- The Enhancer Ant task is now moved to org.datanucleus.enhancer.EnhancerTask
- Various DataNucleus internal classes have been refactored. Please refer to the
for details of upgrading DataNucleus internal API calls
- Many "simple" Java field types now default to persistent (all supported types are now set
to default persistent). Additionally many "simple" types default to being in the DFG whereas
they used not to (i.e you had to enable the persistence of them, e.g java.sql.Date)
Migration from 3.1.1 to 3.1.2
Migrating from AccessPlatform 3.1.1 to 3.1.2 will require no changes.
Migration from 3.1.0.RELEASE to 3.1.1
Migrating from AccessPlatform 3.1.0.RELEASE to 3.1.1 will require no changes.
Migration from 3.1.0.M5 to 3.1.0.RELEASE
Migrating from AccessPlatform 3.1.0.M5 to 3.1.0.RELEASE will require the following changes.
- You no longer are required to specify the persistence property
datanucleus.rdbms.stringDefaultLength as 255 for JDO; this is its new default
Migration from 3.1.0.M4 to 3.1.0.M5
Migrating from AccessPlatform 3.1.0.M4 to 3.1.0.M5 will require no changes.
Migration from 3.1.0.M3 to 3.1.0.M4
Migrating from AccessPlatform 3.1.0.M3 to 3.1.0.M4 will require the following changes.
- The enhancer (v3.1) is now upgraded and requires ASM v4.0+. You can continue to use
the v3.0 enhancer with ASM v3.x but that will not work completely with JDK1.7
- The RDBMS plugin now requires JDK1.6+ to run. Use v3.0 if you are still using JDK1.5
Migration from 3.1.0.M2 to 3.1.0.M3
Migrating from AccessPlatform 3.1.0.M2 to 3.1.0.M3 will require the following changes.
- Persistence property datanucleus.managedRuntime replaced by datanucleus.jmxType
defining the JMX server to use.
- Persistence property datanucleus.datastoreTransactionDelayOperations is removed and
replaced by datanucleus.flush.mode with values of MANUAL and AUTO. MANUAL means that operations
will only go to the datastore on flush/commit, whereas AUTO will send them immediately.
- The persistence property datanucleus.nontx.atomic previously only included persists and
deletes. It now also encompasses field updates. Bear this in mind when considering behaviour
- The value strategy chosen when "native"(JDO)/"auto"(JPA) is specified has changed. It will now
take "identity"/"sequence"/"increment" when numeric-based (first that is supported for that datastore)
and "uuid-hex" when string-based. For RDBMS, use persistence property
datanucleus.rdbms.useLegacyNativeValueStrategy as true if wanting the old process.
Migration from 3.1.0.M1 to 3.1.0.M2
Migrating from AccessPlatform 3.1.0.M1 to 3.1.0.M2 will require the following changes.
- "javax.cache" is now split into "jcache" (old API) and "javax.cache" (standard API) and
the standard API is now supported in datanucleus-core
- datanucleus-management plugin is now merged into datanucleus-core
Migration from 3.0.x to 3.1.0.M1
Migrating from AccessPlatform 3.0 to 3.1.0.M1 will require the following changes.
- Excel, ODF, MongoDB and HBase plugins now respect JDO/JPA table/column naming strategies.
Make sure that you set the table/column names explicitly if requiring some other naming that
was default with v3.0 and earlier plugins
- If you have any "type" plugins using the ObjectStringConverter or ObjectLongConverter interface
please rewrite them to use the new TypeConverter interface (minimal changes).
Migration from 3.0.3 to 3.0.4
Migrating from AccessPlatform 3.0.3 to 3.0.4 will require the following changes.
- Move java.awt geometric type support into datanucleus-awtgeom plugin
Migration from 3.0.2 to 3.0.3
Migrating from AccessPlatform 3.0.2 to 3.0.3 will require no changes.
Migration from 3.0.1 to 3.0.2
Migrating from AccessPlatform 3.0.1 to 3.0.2 will require the following changes.
- HBase : Default behaviour was to use Java serialisation to get the bytes of the PK
of objects. This is changed to now use HBase Bytes.toBytes resulting in cleaner PK ROW ID. To get
the old behaviour set the persistence property datanucleus.hbase.serialisePK
- HBase : default behaviour used to be to persist primitive wrapper fields as serialized.
They are now persisted as serialised if specified in metadata, otherwise using HBase Bytes handler
Migration from 3.0.0 M6 to 3.0.0 RELEASE
Migrating from AccessPlatform 3.0.0 M6 to 3.0.0 RELEASE will require no changes.
Migration from 3.0.0 M5 to 3.0.0 M6
Migrating from AccessPlatform 3.0.0 M5 to 3.0.0 M6 will require the following changes.
- The plugin attribute "override" utilised by "java_type", "store_mapping" and "rdbms_mapping" is
now removed, and users should make use of the attribute "priority" (specify a number and the higher
the number the higher the priority that plugin extension gets.
- JPA usage now defaults to use "datanucleus.RetainValues". This means that when an object
leaves a transaction it will not move to HOLLOW state, but instead to PERSISTENT NONTRANSACTIONAL
and has its field values intact.
- If using an identity string translator, note that this is now a IdentityStringTranslator and the
persistence property is now "datanucleus.identityStringTranslatorType"
Migration from 3.0.0 M4 to 3.0.0 M5
Migrating from AccessPlatform 3.0.0 M4 to 3.0.0 M5 should require no changes.
Migration from 3.0.0 M3 to 3.0.0 M4
Migrating from AccessPlatform 3.0.0 M3 to 3.0.0 M4 will require the following changes.
- Maven2 plugin option "outputFile" is renamed to "ddlFile" for consistency with all docs/tools
Migration from 3.0.0 M2 to 3.0.0 M3
Migrating from AccessPlatform 3.0.0 M2 to 3.0.0 M3 will require the following changes.
- Anyone using "memcache" cache provider should rename it to "spymemcached". This renaming
is to clarify which implementation of "memcached" is actually being used. Similarly the
persistence properties are now spelt "memcached" instead of "memcache". Also the former property
datanucleus.cache.level2.memcached.keyprefix is dropped and users should use
- HBase : previously all primitives were stored serialised. Set the metadata 'serialized'
flag on the field/property to continue doing that.
- Queries are no longer run in a separate thread (which was the previous way of supporting
query cancellation, now reworked for RDBMS to use SQL error codes).
- Persistence properties for schema validation datanucleus.validateXXX now default to false
Migration from 3.0.0 M1 to 3.0.0 M2
Migrating from AccessPlatform 3.0.0 M1 to 3.0.0 M2 will require the following changes.
- The connection password decryption interface has been repackaged/renamed to
org.datanucleus.store.encryption.ConnectionEncryptionProvider so if you were
providing your own decryption of passwords then rebuild to this
- If using your own DataNucleus plugins, make sure you specify the persistence property
datanucleus.plugin.allowUserBundles as true since the default is now to just
use official DataNucleus plugins.
- The identifier naming strategy datanucleus has been renamed to datanucleus1
to make it clearer that it was used as the default for DataNucleus v1.x but no longer
Migration from 2.2.x to 3.0.0 M1
Migrating from AccessPlatform 2.2.x to 3.0.0 M1 will require the following changes.
- JDO API has been moved into its own plugin "datanucleus-api-jdo" and you will need this
if using the JDO API. JDO classes have been repackaged to org.datanucleus.api.jdo
and this is of particular importance for your PMF class
- "datanucleus-jpa" jar has been repackaged as "datanucleus-api-jpa" and the classes within
repackaged to "org.datanucleus.api.jpa". In particular your JPA persistence provider
class should reference this new package name
- "datanucleus-rest" jar has been repackaged as "datanucleus-api-rest".
- SchemaTool (and its Ant task) has been moved in package to org.datanucleus.store.schema
- HBase : generation of "family name" has changed when previously specifying a column name
without a colon; previously used that as family name and qualifier name, but now uses
the table name as the family name in that situation.
- HBase : previously all relationships were stored serialised. Set the metadata 'serialized'
flag on the field/property to continue doing that.
Migration from 2.2.0 RELEASE to 2.2.1
Migrating from AccessPlatform 2.2.0 RELEASE to 2.2.1 will require the following changes.
- JDO 3.1 changes the return type of JDOQL "AVG" to be double or BigDecimal depending
on the type being averaged (previously just returned the same type as the averaged type).
Migration from 2.2.0 Milestone3 to 2.2.0 RELEASE
Migrating from AccessPlatform 2.2.0 M3 to 2.2.0 RELEASE will require the following changes.
- datanucleus-connectionpool is no longer provided/needed, and is included within
datanucleus-rdbms. In addition, if using JDK1.6 you can use a builtin DBCP connection pool.
You still need to include the relevant connection pool (e.g DBCP) in your CLASSPATH if using
- If you experience different behaviour with delete of objects with Excel or ODF, this is
because they now support cascade-delete
- Major changes have been made to the use of the L2 cache (so that fields are used from there
rather than from the datastore wherever possible) and also to Managed Relations. Please report
Migration from 2.2.0 Milestone2 to 2.2.0 Milestone3
Migrating from AccessPlatform 2.2.0 M2 to 2.2.0 M3 will require the following changes.
- Persistence property datanucleus.attachPolicy was removed since no longer
needed - the default attach handler copes with all situations.
- Much improved support for collections/arrays/maps containing nulls is now present
to better match the Java spec for types. If any problems come up, make use of the
"allow-nulls" extension metadata
- JPA Criteria query annotation processor is now in its own plugin jar known as
- JDO Typesafe query annotation processor is now in its own plugin jar known as
Migration from 2.2.0 Milestone1 to 2.2.0 Milestone2
Migrating from AccessPlatform 2.2.0 M1 to 2.2.0 M2 will require the following changes.
- NucleusJDOHelper methods for getting dirty/loaded fields have been improved.
Check the docs for the new method names.
- JDO3.1 sequence changes allow specification of "allocationSize" and "initialValue".
These default to 50 and 1 respectively. Set them for your sequences as required.
The persistence properties now become only fallback values
Migration from 2.1.x to 2.2.0 Milestone1
Migrating from AccessPlatform 2.1.x to 2.2.0 M1 will require the following changes.
- Legacy JDOQL implementation for RDBMS is now dropped. Use AccessPlatform 2.1 if you
Migration from 2.1.2 to 2.1.3
Migrating from AccessPlatform 2.1.2 to 2.1.3 will require the following changes.
- Persistence property datanucleus.attachPolicy is now removed, and
the default handling should work fine
Migration from 2.1.1 to 2.1.2
Migrating from AccessPlatform 2.1.1 to 2.1.2 will require the following changes.
- The metadata extension index that is used to specify a column position (in table)
was previously required under "field" for Excel/ODF plugins.
It should be under "column" now
Migration from 2.1.0 RELEASE to 2.1.1
Migrating from AccessPlatform 2.1.0 RELEASE to 2.1.1 will require the following changes.
- Default allocation size for increment and sequence value strategies have
been changed for JDO usage to 10 and 10 respectively (from 5 and 1). You can configure
the global defaults via persistence properties
Migration from 2.1.0 Milestone3 to 2.1.0 RELEASE
Migrating from AccessPlatform 2.1.0 M3 to 2.1.0 RELEASE will require the following changes.
- Move to using JDO3 jar instead of JDO 2.3 "ec"
- Dropped support for class-level metadata extension "cacheable"; use standardised
cacheable attribute (or annotation) instead.
Migration from 2.1.0 Milestone2 to 2.1.0 Milestone3
Migrating from AccessPlatform 2.1.0 M2 to 2.1.0 M3 will require no changes.
Migration from 2.1.0 Milestone1 to 2.1.0 Milestone2
Migrating from AccessPlatform 2.1.0 M1 to 2.1.0 M2 will require the following changes.
- JPQL "CASE" statements are now supported
- JPA2 static metamodel is now supported, and so can be used with criteria queries
alongside the string-based field specification method
- Runtime enhancement is now turned off by default even when you use JDK1.6+ and have
the enhancer/core jars in the CLASSPATH. Specify the compiler argument processor
to enable it (see docs)
Migration from 2.0.x to 2.1.0 Milestone1
Migrating from AccessPlatform 2.0.x to 2.1.0 M1 will require the following changes.
- The JDOQL implementation used for RDBMS is now the rewritten "generic" implementation.
To use the old implementation, set the JDOQL implementation as "JDOQL-Legacy"
- Use of JPA should be run against the JPA2 "final" jar (or its Apache Geronimo specs equivalent)
- Heavy refactoring has been done internally so if relying on DataNucleus APIs you
should check against SVN for changes. In particular, plugins should be using ObjectProvider
instead of StateManager, and ExecutionContext in place of ObjectManager.