Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "EMF/Teneo 1.0.4/EclipseLink Support"

< EMF
(→‎Accessing EMF Models in Databases using the EclipseLink Resource and URIs)
(→‎Accessing EMF Models in Databases using the EclipseLink Resource and URIs)
Line 9: Line 9:
  
 
== Accessing EMF Models in Databases using the EclipseLink Resource and URIs ==
 
== Accessing EMF Models in Databases using the EclipseLink Resource and URIs ==
 +
 +
=== Understanding the principles ===
  
 
Teneo/EclipseLink provides a full implementation of EMF's Resource interface named ''EclipseLinkResourceImpl''. It enables applications to load and save EMF models from or to relational databases and to manage their lifecycle directly through EMF's built-in persistence API, i.e. the ''ResourceSet'' interface. ''EclipseLinkResourceImpl'' represents an almost complete abstraction from JPA mappings and EclipseLink runtime APIs and makes accessing models in databases, from an EMF point of view, as natural as loading or saving models from files.
 
Teneo/EclipseLink provides a full implementation of EMF's Resource interface named ''EclipseLinkResourceImpl''. It enables applications to load and save EMF models from or to relational databases and to manage their lifecycle directly through EMF's built-in persistence API, i.e. the ''ResourceSet'' interface. ''EclipseLinkResourceImpl'' represents an almost complete abstraction from JPA mappings and EclipseLink runtime APIs and makes accessing models in databases, from an EMF point of view, as natural as loading or saving models from files.
Line 15: Line 17:
  
 
The EclipseLink URIs provide the information required for accessing models in databases. Compared to accessing models in files there are two major differences:
 
The EclipseLink URIs provide the information required for accessing models in databases. Compared to accessing models in files there are two major differences:
−
1/ Resource location: In addition to the path or URL of the resource some additional access parameters need to be specified. Most importantly these are JDBC driver, user name, password.
+
# '''Resource location''': In addition to the path or URL of the resource some additional access parameters need to be specified. Most importantly these are JDBC driver, user name, password.
−
2/ Resource contents: Loading models from files is based on the implicit assumptions that the file's whole contents belongs to the model. In the case of databases this is rather unlikely, typically a smaller or bigger number of different models would be present in the same database. Therefore, the model that is to be accessed within a given database needs to be specified in some way.
+
# '''Resource contents''': Loading models from files is based on the implicit assumption that the file's whole content belongs to the model that is to be loaded. In the case of databases this is assumption doesn't make much sense since they would be used to persist multiple models but not just a single one and EclipseLink resources are expected to contain a subset rather than all of those models. Therefore, the model that is to be accessed within a given database needs to be specified in some way.
−
 
+
For these reasons, EclipseLink URIs are composed as follows:
−
<code>eclipselink://sessionName?contentsQueryAlias</code>
+
: <code>eclipselink:///persistenceUnitName?contentsQuery</code>
−
 
+
−
Persistence Unit Database access parameters (database URL, JDBC driver, user name, password)
+
−
Contents query
+
−
 
+
−
A EclipseLink resource typically contains a certain subset of objects stored in the underlying database. It is identified by the URI passed to or created by its constructor. This URI must or will be a EclipseLink URI and indicates an optional database login, a database session declared in the EclipseLink sessions configuration (sessions.xml), and a query returning the objects which constitute the contents of the EclipseLink resource.
+
  
 +
''persistenceUnitName'' specifies the name of the applicable JPA (TODO add reference) persistence unit (TODO add reference) declared in the JPA persistence configuration file (''persistence.xml''). The persistence configuration file is expected to be provided on the application's classpath; its path or URL therefore doesn't need to be specified explicitly. The persistence unit is an entity providing all necessary parameters for accesssing a given database - including database URL, the JDBC driver to be used, user name and password, etc. - and for initializing the EclipseLink runtime appropriately.
  
 +
''contentsQuery'' yields a query written in JPQL (TODO add reference). It refers to the root object(s) of the model(s) in the given database that will constitute the contents of the underlying EclipseLink resource. Contents queries thereby enable the contents of EclipseLink resources to be limited to any subset of models or even to fragments of models being present in a database.
  
−
The EclipseLink URI protocol includes all parameters which are
+
=== Putting things in practice ===
  
−
===  
+
==== Saving a model to a new EclipseLink resource ====
  
 
   // create sample instance of library model
 
   // create sample instance of library model

Revision as of 04:33, 23 March 2009

Teneo 1.0.4 provides support for EclipseLink. The following sections explain the principal features it includes and give advice how they can be used for building model-based applications on top of relational databases.

Creating EclipseLink/JPA Mappings for EMF models

Three possibilities:

  • Model-driven
  • Meet-in-the-middle
  • Schema-driven

Accessing EMF Models in Databases using the EclipseLink Resource and URIs

Understanding the principles

Teneo/EclipseLink provides a full implementation of EMF's Resource interface named EclipseLinkResourceImpl. It enables applications to load and save EMF models from or to relational databases and to manage their lifecycle directly through EMF's built-in persistence API, i.e. the ResourceSet interface. EclipseLinkResourceImpl represents an almost complete abstraction from JPA mappings and EclipseLink runtime APIs and makes accessing models in databases, from an EMF point of view, as natural as loading or saving models from files.

Along with EclipseLinkResourceImpl a dedicated eclipselink URI protocol and a underlying resource factory named EclipseLinkResourceFactoryImpl have been defined. EclipseLink URIs enable models in databases to be referenced and the EclipseLink resource factory makes sure that instances of EclipseLinkResourceImpl are used to load and save such models.

The EclipseLink URIs provide the information required for accessing models in databases. Compared to accessing models in files there are two major differences:

  1. Resource location: In addition to the path or URL of the resource some additional access parameters need to be specified. Most importantly these are JDBC driver, user name, password.
  2. Resource contents: Loading models from files is based on the implicit assumption that the file's whole content belongs to the model that is to be loaded. In the case of databases this is assumption doesn't make much sense since they would be used to persist multiple models but not just a single one and EclipseLink resources are expected to contain a subset rather than all of those models. Therefore, the model that is to be accessed within a given database needs to be specified in some way.

For these reasons, EclipseLink URIs are composed as follows:

eclipselink:///persistenceUnitName?contentsQuery

persistenceUnitName specifies the name of the applicable JPA (TODO add reference) persistence unit (TODO add reference) declared in the JPA persistence configuration file (persistence.xml). The persistence configuration file is expected to be provided on the application's classpath; its path or URL therefore doesn't need to be specified explicitly. The persistence unit is an entity providing all necessary parameters for accesssing a given database - including database URL, the JDBC driver to be used, user name and password, etc. - and for initializing the EclipseLink runtime appropriately.

contentsQuery yields a query written in JPQL (TODO add reference). It refers to the root object(s) of the model(s) in the given database that will constitute the contents of the underlying EclipseLink resource. Contents queries thereby enable the contents of EclipseLink resources to be limited to any subset of models or even to fragments of models being present in a database.

Putting things in practice

Saving a model to a new EclipseLink resource

 // create sample instance of library model
 Library library1 = LibraryFactory.eINSTANCE.createLibrary();
 library.setName("library1");

 // create EclipseLink URI for saving/loading library model in/from database
 String query = EclipseLinkResourceUtil.createContentsEqualQuery(LibraryPackage.eINSTANCE.getLibrary(),LibraryPackage.eINSTANCE.getLibrary_Name(), library1.getName());
 uri = EclipseLinkResourceUtil.createEclipseLinkURI("library", query);

 // save library model instance in database
 ResourceSet resourceSet1 = new ResourceSetImpl();
 resourceSet1.getLoadOptions().putAll(getTestPersistenceUnitProperties());
 resource1 = resourceSet1.createResource(uri);

 assertTrue(resource1 instanceof EclipseLinkResourceImpl);
 assertFalse(resource1.isLoaded());

 resource1.getContents().add(library1);

 assertTrue(resource1.isLoaded());

 resource1.save(null);

Building Model-based Rich Client Applications on top of Teneo and EclipseLink

--Stephaneberle9.gmail.com 05:16, 16 March 2009 (UTC)

Retrieved from "https://wiki.eclipse.org/index.php?title=EMF/Teneo_1.0.4/EclipseLink_Support&oldid=145846"

Back to the top