Support for Spring Data JPA

[Torsten Juergeleit]

I would like to discuss some details about a cartridge for Spring Data JPA (as described in #99):

The idea is to use Spring Data JPA repository interfaces instead of Sculptors generated repository implementation classes which are using Sculptor JPA runtime classes.

To get an idea of Spring Data JPAs interface-based approach Oliver Gierkes blog posts Getting started with Spring Data JPA and Advanced Spring Data JPA - Specifications and Querydsl are a good introduction.

Spring Data JPA supports most of the stuff provided by Sculptors generic access objects with its Dynamic Finders and Pagination, e.g.

• built-in CRUD operations
• built-in support for sorting and paging
• named queries with named query parameters in repository interfaces
• built-in support for QueryDsl predicates
• support for custom repository operation

To use theses features only a Java interface (which extends from one of the Spring Data interfaces with the corresponding repository abstraction) has to be implemented. Ok, for custom repository implementations an implementation class is needed as well.

The prototype provides the following features:

• generation of repository interface extending QueryDslPredicateExecutor -> all repository operations which have the same name as Spring Data JPAs built-in ones are ignored (we have to keep them in the model to allow references from with services)
• generation of custom repository interface (extending the aforementioned interface) and implementation stub with repository methods marked as "gap"

Currently I'm working on the support for named queries in the generated interface via the @Query annotation and named query parameters with the @Param annotation.

Any thoughts?

/Torsten

[Ron Smith]

Sounds like it supports most everything we would do ourselves.  If we want to provide additional generated methods, is there anything preventing us from doing it?

Ron

[Torsten Juergeleit]

> If we want to provide additional generated methods, is there anything preventing us from doing it?

For these methods a separate interface (same name as corresponding repository interface but suffixed with "Custom") and an implementation class (plain Spring bean independant from Spring Data) have to be implemented. Our Spring Data repository interface needs to extend from this custom interface (in addition to the Spring Data repository abstraction interface). Spring Data automatically detects this custom interface with its implementation and refers to the corresponding custom repository methods.

A detailed description can be found in Spring Data JPAs reference manual (section Adding custom behavior to single repositories).


We will need this extension mechanism for implementing Sculptors Subscribe support in Spring Data repositories (the aforementioned custom interface has to extend Sculptors EventSubscriber interface).

But right now I have no clue how to implement Sculptors Publish support for Spring Datas built-in repository operations.
Any ideas?

/Torsten