Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "EclipseLink/Examples/JPA/Migration/OracleTopLinkNative/Cascading"
| Line 1: | Line 1: | ||
<center>[[image:Catnicon.gif]] '''''UNDER CONSTRUCTION''''' [[image:Catnicon.gif]]<br/>This content being developed here with with the intent to be added to the [http://www.eclipse.org/eclipselink/documentation/2.4/solutions/migrnativetoplink.htm docs]</center> | <center>[[image:Catnicon.gif]] '''''UNDER CONSTRUCTION''''' [[image:Catnicon.gif]]<br/>This content being developed here with with the intent to be added to the [http://www.eclipse.org/eclipselink/documentation/2.4/solutions/migrnativetoplink.htm docs]</center> | ||
| + | |||
| + | |||
| + | == The Problem == | ||
| + | |||
| + | When migrating from the native TopLink API to JPA one of the major differences in behaviour is how relationships between entities are managed within transactions. The native TopLink approach within the UnitOfWork is 'persistence-by-reachability' while JPA leverages explicit [http://www.eclipse.org/eclipselink/api/2.0/javax/persistence/CascadeType.html CascadeType] setting on the mappings to determine how they are managed/used for DETACH, MERGE, PERSIST, REFRESH, and REMOVE. When migrating an application that was written using TopLink's original native API care must be taken to configure cascading or alter your application's transaction logic to ensure the same functionality is maintained. | ||
| + | |||
| + | == Scenarios == | ||
| + | |||
| + | The following are some key scenarios. | ||
| + | |||
| + | === New Entity Discovery === | ||
| + | |||
| + | With JPA entities should never be discovered. They must be explicitly registered with an entity manager (persist) or they must be included as a dependent child within a relationship with cascade PERSIST enabled. If a new entity instance is found within a relationship and it has not been persisted or merged into the EntityManager an exception will be thrown during commit or flush. | ||
| + | |||
| + | === Persist vs Merge === | ||
| + | |||
| + | TODO: Discuss the use of the 2 methods and when they should be used for both new entities, existing detached entities, and managed entities. | ||
Latest revision as of 08:26, 11 February 2013
UNDER CONSTRUCTION This content being developed here with with the intent to be added to the docs
The Problem
When migrating from the native TopLink API to JPA one of the major differences in behaviour is how relationships between entities are managed within transactions. The native TopLink approach within the UnitOfWork is 'persistence-by-reachability' while JPA leverages explicit CascadeType setting on the mappings to determine how they are managed/used for DETACH, MERGE, PERSIST, REFRESH, and REMOVE. When migrating an application that was written using TopLink's original native API care must be taken to configure cascading or alter your application's transaction logic to ensure the same functionality is maintained.
Scenarios
The following are some key scenarios.
New Entity Discovery
With JPA entities should never be discovered. They must be explicitly registered with an entity manager (persist) or they must be included as a dependent child within a relationship with cascade PERSIST enabled. If a new entity instance is found within a relationship and it has not been persisted or merged into the EntityManager an exception will be thrown during commit or flush.
Persist vs Merge
TODO: Discuss the use of the 2 methods and when they should be used for both new entities, existing detached entities, and managed entities.