|
|
|
|
@@ -1,7 +1,7 @@
|
|
|
|
|
[[jpa.repositories]]
|
|
|
|
|
= JPA Repositories
|
|
|
|
|
|
|
|
|
|
This chapter includes details of the JPA repository implementation.
|
|
|
|
|
This chapter will point out the specialties for repository support for JPA. This builds on the core repository support explained in <<repositories>>. So make sure you've got a sound understanding of the basic concepts explained there.
|
|
|
|
|
|
|
|
|
|
[[jpa.introduction]]
|
|
|
|
|
== Introduction
|
|
|
|
|
@@ -36,7 +36,7 @@ Using this element looks up Spring Data repositories as described in <<repositor
|
|
|
|
|
Beyond the default attributes of the `repositories` element the JPA namespace offers additional attributes to gain more detailed control over the setup of the repositories:
|
|
|
|
|
|
|
|
|
|
.Custom JPA-specific attributes of the repositories element
|
|
|
|
|
[cols="1,3"]
|
|
|
|
|
[options = "autowidth"]
|
|
|
|
|
|===============
|
|
|
|
|
|`entity-manager-factory-ref`|Explicitly wire the `EntityManagerFactory` to be used with the repositories being detected by the `repositories` element. Usually used if multiple `EntityManagerFactory` beans are used within the application. If not configured we will automatically lookup the `EntityManagerFactory` bean with the name `entityManagerFactory` in the `ApplicationContext`.
|
|
|
|
|
|`transaction-manager-ref`|Explicitly wire the `PlatformTransactionManager` to be used with the repositories being detected by the `repositories` element. Usually only necessary if multiple transaction managers and/or `EntityManagerFactory` beans have been configured. Default to a single defined `PlatformTransactionManager` inside the current `ApplicationContext`.
|
|
|
|
|
@@ -104,7 +104,7 @@ Saving an entity can be performed via the `CrudRepository.save(…)`-Method. It
|
|
|
|
|
Spring Data JPA offers the following strategies to detect whether an entity is new or not:
|
|
|
|
|
|
|
|
|
|
.Options for detection whether an entity is new in Spring Data JPA
|
|
|
|
|
[cols="1,3"]
|
|
|
|
|
[options = "autowidth"]
|
|
|
|
|
|===============
|
|
|
|
|
|Id-Property inspection (*default*)|By default Spring Data JPA inspects the identifier property of the given entity. If the identifier property is `null`, then the entity will be assumed as new, otherwise as not new.
|
|
|
|
|
|Implementing `Persistable`|If an entity implements `Persistable`, Spring Data JPA will delegate the new detection to the `isNew(…)` method of the entity. See the link:$$http://docs.spring.io/spring-data/data-commons/docs/current/api/index.html?org/springframework/data/domain/Persistable.html$$[JavaDoc] for details.
|
|
|
|
|
@@ -120,7 +120,7 @@ Spring Data JPA offers the following strategies to detect whether an entity is n
|
|
|
|
|
The JPA module supports defining a query manually as String or have it being derived from the method name.
|
|
|
|
|
|
|
|
|
|
==== Declared queries
|
|
|
|
|
Although getting a query derived from the method name is quite convenient, one might face the situation in which either the method name parser does not support the keyword one wants to use or the method name would get unnecessarily ugly. So you can either use JPA named queries through a naming convention (see <<jpa.query-methods.named-queries>> for more information) or rather annotate your query method with @Query (see <<jpa.query-methods.at-query>> for details).
|
|
|
|
|
Although getting a query derived from the method name is quite convenient, one might face the situation in which either the method name parser does not support the keyword one wants to use or the method name would get unnecessarily ugly. So you can either use JPA named queries through a naming convention (see <<jpa.query-methods.named-queries>> for more information) or rather annotate your query method with `@Query` (see <<jpa.query-methods.at-query>> for details).
|
|
|
|
|
|
|
|
|
|
[[jpa.query-methods.query-creation]]
|
|
|
|
|
=== Query creation
|
|
|
|
|
@@ -139,7 +139,7 @@ We will create a query using the JPA criteria API from this but essentially this
|
|
|
|
|
====
|
|
|
|
|
|
|
|
|
|
.Supported keywords inside method names
|
|
|
|
|
[options="header", cols="1,1,2"]
|
|
|
|
|
[options = "header, autowidth"]
|
|
|
|
|
|===============
|
|
|
|
|
|Keyword|Sample|JPQL snippet
|
|
|
|
|
|`And`|`findByLastnameAndFirstname`|`… where x.lastname = ?1 and x.firstname = ?2`
|
|
|
|
|
@@ -251,7 +251,7 @@ public interface UserRepository extends JpaRepository<User, Long> {
|
|
|
|
|
|
|
|
|
|
Using advanced `LIKE` expressionsThe query execution mechanism for manually defined queries using @Query allow the definition of advanced `LIKE` expressions inside the query definition.
|
|
|
|
|
|
|
|
|
|
.Advanced `LIKE` expressions in @Query
|
|
|
|
|
.Advanced like-expressions in @Query
|
|
|
|
|
====
|
|
|
|
|
[source, java]
|
|
|
|
|
----
|
|
|
|
|
@@ -273,7 +273,7 @@ Native queriesThe `@Query` annotation allows to execute native queries by settin
|
|
|
|
|
----
|
|
|
|
|
public interface UserRepository extends JpaRepository<User, Long> {
|
|
|
|
|
|
|
|
|
|
@Query(value = "SELECT * FROM USERS WHERE EMAIL`ADDRESS = ?0", nativeQuery = true)
|
|
|
|
|
@Query(value = "SELECT * FROM USERS WHERE EMAIL_ADDRESS = ?0", nativeQuery = true)
|
|
|
|
|
User findByEmailAddress(String emailAddress);
|
|
|
|
|
}
|
|
|
|
|
----
|
|
|
|
|
@@ -296,8 +296,8 @@ public interface UserRepository extends JpaRepository<User, Long> {
|
|
|
|
|
@Param("firstname") String firstname);
|
|
|
|
|
}
|
|
|
|
|
----
|
|
|
|
|
Note that the method parameters are switched according to the occurrence in the query defined.
|
|
|
|
|
====
|
|
|
|
|
Note that the method parameters are switched according to the occurrence in the query defined.
|
|
|
|
|
|
|
|
|
|
[[jpa.query.spel-expressions]]
|
|
|
|
|
=== Using SpEL expressions
|
|
|
|
|
@@ -305,13 +305,13 @@ Note that the method parameters are switched according to the occurrence in the
|
|
|
|
|
As of Spring Data JPA release 1.4 we support the usage of restricted SpEL template expressions in manually defined queries via `@Query`. Upon query execution these expressions are evaluated against a predefined set of variables. We support the following list of variables to be used in a manual query.
|
|
|
|
|
|
|
|
|
|
.Supported variables inside SpEL based query templates
|
|
|
|
|
[options="header", cols="1,3"]
|
|
|
|
|
[options="header, autowidth"]
|
|
|
|
|
|===============
|
|
|
|
|
|Variable|Usage|Description
|
|
|
|
|
|`entityName`|`select x from #{#entityName} x`|Inserts the `entityName` of the domain type associated with the given Repository. The `entityName` is resolved as follows: If the domain type has set the name property on the `@Entity` annotation then it will be used. Otherwise the simple class-name of the domain type will be used.
|
|
|
|
|
|===============
|
|
|
|
|
|
|
|
|
|
The following example demonstrates one use case for the `#{#entityName}` expression in a query string where you want to define a repository interface with a query method with a manually defined query. In order not to have to state the actual entity name in the query string of a `@Query` annotation one can use the `#{#entityName}` Variable.
|
|
|
|
|
The following example demonstrates one use case for the `+#{#entityName}+` expression in a query string where you want to define a repository interface with a query method with a manually defined query. In order not to have to state the actual entity name in the query string of a `@Query` annotation one can use the `+#{#entityName}+` Variable.
|
|
|
|
|
|
|
|
|
|
[NOTE]
|
|
|
|
|
====
|
|
|
|
|
@@ -405,8 +405,8 @@ public interface UserRepository extends Repository<User, Long> {
|
|
|
|
|
Page<User> findByLastname(String lastname, Pageable pageable);
|
|
|
|
|
}
|
|
|
|
|
----
|
|
|
|
|
The just shown declaration would apply the configured `@QueryHint` for that actually query but omit applying it to the count query triggered to calculate the total number of pages.
|
|
|
|
|
====
|
|
|
|
|
The just shown declaration would apply the configured `@QueryHint` for that actually query but omit applying it to the count query triggered to calculate the total number of pages.
|
|
|
|
|
|
|
|
|
|
[[jpa.entity-graph]]
|
|
|
|
|
=== Configuring Fetch- and LoadGraphs
|
|
|
|
|
@@ -716,9 +716,9 @@ interface UserRepository extends Repository<User, Long> {
|
|
|
|
|
----
|
|
|
|
|
====
|
|
|
|
|
|
|
|
|
|
:leveloffset: 2
|
|
|
|
|
:leveloffset: +1
|
|
|
|
|
include::{spring-data-commons-docs}/auditing.adoc[]
|
|
|
|
|
:leveloffset: 0
|
|
|
|
|
:leveloffset: -1
|
|
|
|
|
|
|
|
|
|
[[jpa.auditing]]
|
|
|
|
|
== JPA Auditing
|
|
|
|
|
@@ -883,3 +883,4 @@ class RepositoryClient {
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
----
|
|
|
|
|
|
|
|
|
|
|
Oliver Gierke