2. Elexis Entwicklertreffen19./20. November 2011

Alternative Elexis persistence implementation based on

JPA/EclipseLink

Marco Descher, MEDEVIT, Austria

Status quo: Structure

● PersistentObject is the superclass of all classes in need of DB persistence

● Properties are mapped using static Strings to their respective columns in the DB

● There is transparentconversion of data(s.a. compression,transformation etc.)

● PersistentObject createsand handles the JDBCconnection to a databaseresource

Status Quo: „Getting“ objects

● Instances of objects are aquired by the following methods

● Static access, e.g. Patient.loadByPatientId● StoreToString via

PersistentObjectFactory.createFromString● but mainly Queries s. a. Query<Patient> qbe = new

Query<Patient>(Patient.class)● Plug-Ins declaring persistent objects register a

PersistentObjectFactory to get their data types included into the Query (classloaders in bundles are separated) → This however is already a level higher than the persistence architecture we are talking about ...

Status Quo: Layer separation

● Example: ch.elexis.data.Patient

● The entire persistencevertical is realized withinone chain of subclasses

● Everything is based uponreal objects

● Problematic for future dev-elopment → 3layer, android..

● However → Gerry started ch.elexis.core whichis in an early stage!

isDragOk()

createFallundKons()

loadByPatientId()

connect()

„The alternative approach“ Technologies

● JNDIJava Naming and Directory Interface

● Flyway - http://code.google.com/p/flyway/

Database migration framework

● JPA / EclipseLink - http://www.eclipse.org/eclipselink/

TechnologiesJava Naming and Directory Interface (JNDI) 1/2

● The Java Naming and Directory Interface (JNDI) is part of the Java platform, providing applications based on Java technology with a unified interface to multiple naming and directory services.

● But what for?

● To register data sources! → http://download.oracle.com/javase/1.4.2/docs/guide/jdbc/getstart/datasource.html

● Okay, but whats the meaning of that?

● The plug-in is not directly dependent on any JDBC instantion like Mysql, Pgsql, you name it.

● Separate configuration

● Connection pooling etc.

TechnologiesJava Naming and Directory Interface (JNDI) 2/2

MySQL Data Source registered unter the name „elexisMain“ on the local JNDI Server

elexisMainAnd JPA?

JPA only needs the name of the dataSource to connect to set up within persistence.xml → we'll come to that!

And JNDI is standard within EE containers which will come in handy for Elexis 3 …

TechnologiesFlyway

● Change management currently done by ch.elexis.util.DBUpdate for the core and the persistence-classes themselves

● Version of the table stored within the table, needs to be filtered, when selecting all

● Flyway takes care of these tasks, and is independently developed

● Meta-Data about DB is stored in separate table● Accepts both Java classes and SQL-scripts as

input

TechnologiesJPA/EclipseLink

● Part of the Eclipse release train, reference implementation of JPA 2.0

● Skip the intro … @see http://wiki.eclipse.org/Introduction_to_EclipseLink_(ELUG)

● PersistenceUnit defined in persistence.xml is the „entry point for usage“ Manifest.mf

JNDI Data Source

JPA/EclipseLink Concepts and Definitions

● (Annotated) Entities are lightweight persistence domain objects. Typically an entity represents a table in a relational database, and each entity instance corresponds to a row in that table.

● Interfaces are groups of related methods with empty bodies. We separated them into two groups:

● Interfaces for the objects (e.g. IContact, ISticker)● Interfaces for the factories

● Adapters general purpose is to implement an interface. We use the adapters to implement the factories and provide adapter objects to instantiate Entities into the Elexis interface model.

JPA/EclipseLink Concepts and Definitions

● The original approach combined the creation and the object itself within one class (except for the Queries)

● We separated the implementation into

● Adapter objects: knowing about themselves and their abilities

● Factories: responsible for managing the objects. That is, an object does not implement complicated querying stuff.

● Why? Several reasons: E.g. When it comes to further developments it is easy to exchange the objects (e.g. Android may use the model) and implement a web service (separate implementation of the factory as service)

JPA/EclipseLink Plug-In structure

?

To follow

Runs as service on localhost

-Djava.naming.factory.initial=com.sun.jndi.rmi.registry.RegistryContextFactory-Djava.naming.provider.url=rmi://localhost:1099

Once per elexis instance

Once per persistence unit

Bundle names are still under discussion!

JPA/EclipseLink Implementation (e.g. Kontakt Table)

Annotated Entity

Factory

Datamodel

JPA Implementationwith Adapters

E ntity I nterfaceA dapter

Parallel usage of PO/JPA

● Base the JDBC connection on a connection pool data source, provided via JNDI.

● Rewrite PersistentObject to use data source.

● Connect both PO and JPA to the data source.● Write an adapter for the PO ↔ JPA data types.

● To forward Events (e.g. PatientSelection)● To understand „stored-by-classname“ database-

entries (resp. change these to interfaces)● Share usage of jface image and color registry →

circular dependencies

JPA/EclipseLinkMissing topics

● Missing Factory topics● Factory methods for 2-layer-system only● Security → AspectJ?● Logging → Lombok project @Log

projectlombok.org

● Dynamic entities

Status / Tasks / next steps(?)

● Constantly drive the „merge“ to interfaces, resp. the data model

● Outsource DB connection (data source) setup and DB validity check to own plugin? External Setup-Tool, this could be reused later on in the 3-layer-arch

● Change „Foreign Keys“ in Tables from classnames, id to Tabellen-namen, Id or interfacename, id ?