Skip to main content

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.

Jump to: navigation, search

EclipseLink/Development/SDO-JPA

< EclipseLink‎ | Development
Revision as of 16:34, 12 December 2008 by Blaise.doughan.oracle.com (Talk | contribs) (Querying)

EclipseLink Incubator: SDO Data Access Service with JPA

The work is being developed within the EclipseLink/Development/Incubator and is being tracked by bug 258057.

This incubator is intended to illustrate how SDO can be used with JPA to provide relational database access to data exposed as SDO DataObjects. This functionality bridges SDO, JPA, and MOXy components and may also result in the generation of some additional utilities to simplify development tasks and tooling support.

Incubator Exit Criteria

This incubator feature is intended to facilitate rapid development and interaction with consumers. Once each usage scenario is validated with the consumers and the necessary testing is in place the functionality will be migrated back into the main components (SDO, MOXy, JPA, & Core) as well as the necessary test cases being migrated into the corresponding projects.

This incubator feature will continue to evolve functionality until all of the consumer required use cases surrounding SDO usage with JPA have been addressed.

Use Cases

There are several options for using SDO with JPA:

  1. SDO DataObjects wrapping JPA entities. The XSD and DataObject model defined by JAXB mappings on the JPA entities
  2. JPA Mapping of SDO DataObjects

1. SDO DataObjects wrapping JPA entities

In this use case a developer wishes to expose their JPA model as an SDO DataObject model (static or dynamic). The JPA entities are mapped to a XSD through JAXB mappings.

  1. In this use case the developer defines the mapping from the JPA domain model (POJOs) to an XML schema (XSD) using JAXB mappings (annotations or EclipseLink native OXM).
  2. The XSD is then generated using the JAXB Java-XML Compiler (JXC)
  3. The SDO Data Object model is now implicitly define through the use of the generated XSD. If the service developer wishes to use a static DataObject model they can optionally use the SDO compiler to generate this model based on the XSD.

1.1. SDO Bootstrapping

When the application needs to interact with the JPA backed SDO model the service being developed must bootstrap the SDO context. In general SDO usage the context is initialized using something like:

EntityManagerFactory emf = Persistence.createEntityManagerFactory("CustomerExample");      
EntityManager em = emf.createEntityManager();
HelperContext hc = new JPAHelperConext(em);

When using JPA entities behind the SDO model the service developer will need to express the XML schema represenation through JAXB annotations on the JPA entities.

Querying

When developing a service that will return SDO DataObject instances from the relational database the developer will issue queries against the database using JPA (PK Find, JP QL or Native ORM queries in JPA 1.0). The resulting entities will then be wrapped by DataObject using a provided helper class.

EntityManagerFactory emf = Persistence.createEntityManagerFactory("CustomerExample");      
EntityManager em = emf.createEntityManager();
List<MyEntity> entities = em.createQuery("SELECT e FROM MyEntity e WHERE ...").getResultList();
 
HelperContext hc = new JPAHelperConext(em);
List<DataObject> dataObjects = hc.wrap(entities);

Creating (JPA persist)

Creating new entities in the database can be done by explicitly requesting the new data to be persisted. If the DataObject being persisted combines new objects with updates to existing objects then the Updating scenario below will be used.

EntityManagerFactory emf = SdoJpaHelper.getEntityManagerFactory(sdoContext);
EntityManager em = emf.createEntityManager();
 
em.getTransaction().begin();
 
SdoJpaHelper.persist(em, dataObject);
 
em.getTransaction().commit();

Note: The cascade persist configuration on the underlying entity's relationship mappings will define the scope of which new instances in the graph will be persisted.

Updating (JPA merge)

In the case of updates to existing entities as well as addition of new entities through relationships the merge call on the helper will be used.

EntityManagerFactory emf = SdoJpaHelper.getEntityManagerFactory(sdoContext);
EntityManager em = emf.createEntityManager();
 
em.getTransaction().begin();
 
SdoJpaHelper.merge(em, dataObject);
// ... Other operations within the same TX
 
em.getTransaction().commit();

Note: The creation of new objects and the removal of existing objects in the graph result in database operations based on the cascade and private-owned configurations in the JPA model's relationship mappings.

Deleting (JPA remove)

Entities can be removed from the database using the helper's remove call:

EntityManagerFactory emf = SdoJpaHelper.getEntityManagerFactory(sdoContext);
EntityManager em = emf.createEntityManager();
 
em.getTransaction().begin();
 
SdoJpaHelper.remove(em, dataObject);
 
em.getTransaction().commit();

Feature Development

In order to implement the above defined functionality the following development tasks and associated design work is required.

  1. JPA ValueStore
  2. Helper: SdoJpaContext
  3. Examples

JPA Value Store

Within the EclipseLink SDO implementation there is inherent support for wrapping different implementations of a ValueStore (). This interface and supporting mechanics of accessing the values from the new EntityValueStore will be the core of the incubation effort.

EclipseLink-SDO-UML.jpg

SDO-JPA Helper/Context

An approach to bootstrapping and accessing the integrated functionality will be required.

Merge using ChangeSummary

When a developer wishes to persist a DataObject graph and a ChangeSummary is available this solution should leverage the ChangeSummary to avoid calculating the necessary changes based on reading in the objects and doing comparisons.

Back to the top