JPA Data Layer

Date	2013-10-28	Contacts	Jesse Eichar
Status	Motion passed / Done	Release	2.12
Resources	Available	Ticket #	228
Source code	https://github.com/geonetwork/core-geonetwork/tree/spring-data-jpa
Funding	Personal time

Overview

Currently the database access uses the Jeeves Dbms object which requires developers to write SQL code throughout the codebase. This makes it difficult to make changes to database schemas as well as making SQL injection attacks much more possible.

This proposal proposes to change the data layer to use the industry standard Java Persistence API (JPA) for accessing the database.

From an end-users's point of view nothing will have changed. From a developer's point of view all access to data in the database will be through type-checked Java objects. No SQL will be required. In addition all access to the database will be restricted to a single module and based on interfaces and standard Java Objects. This allows for the option of changing the repository in the future in a much less risky way.

Technical Details:

To reduce boiler-plate and to integrate with Spring that is already used in Geonetwork, the Spring-data-JPA project is used as a layer on top of JPA. Hibernate is used as the JPA implementation although no hibernate specific code is used.

A new module (domain) will be added that will contain the domain objects and repositories.
All domain objects are in the package: org.fao.geonet.domain
All Repositories are in the package: org.fao.geonet.repository
All Repositories will extend GeonetRepository interface for some common Geonetwork specific repository methods.
Repositories (as described in Spring-data-JPA) will have:
- A basic interface (IE. MetadataRepository). This contains queries as defined in Spring-Data-JPA. Only the most basic queries are used and often this interface is empty since Specifications have been found to be better for defining queries.
- An optional *RepositoryCustom interface is defined (IE MetadataRepositoryCustom). This contains methods that need an actual implementation. For example findAllIds(). Since this query requires a selection it cannot be defined using simply Specifications or spring-data queries.
- An optional *RepositoryImpl class (IE MetadataRepositoryImpl). This class implements the methods defined in *RepositoryCustom.
All class containing Specifications are defined in: org.fao.geonet.repository.specification
Only CriteriaBuilder is used to create custom queries. This is an API for creating typesafe queries.

Testing

Unit tests are created for all query methods and all specifications
Domain objects do not always have unit tests since they are generated beans and typically do not contain logic. Any method that contains logic does have a unit test
Integration tests have been implemented for some services and harvesters and super classes have been implemented to allow other to implement more integration tests.
AbstractSpringDataIntegrationTest - In domain module
AbstractCoreIntegrationTest - In core module
AbstractServiceIntegrationTest - In services module
AbstractHarvesterServiceIntegrationTest - In harvesting module
AbstractHarvesterIntegrationTest - In harvesting module