Skip to content

JPA Data Layer

Jump to bottom
Jesse Eichar edited this page Nov 8, 2013 · 7 revisions
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

Proposal Type:

  • Type: Improvement
  • Module: All

Voting History

  • Vote Proposed: TBA

Participants

  • All
Clone this wiki locally