DATAJPA-153 - Fixed typos in reference documentation.
This commit is contained in:
@@ -76,7 +76,7 @@
|
||||
<row>
|
||||
<entry><code>transaction-manager-ref</code></entry>
|
||||
|
||||
<entry>Explicitly wire tha
|
||||
<entry>Explicitly wire the
|
||||
<interfacename>PlatformTransactionManager</interfacename> to
|
||||
be used with the repositories being detected by the
|
||||
<code>repositories</code> element. Usually only necessary if
|
||||
@@ -489,7 +489,7 @@ public class User {
|
||||
<para>All the sections above describe how to declare queries to access a
|
||||
given entity or collection of entities. Of course you can add custom
|
||||
modifying behaviour by using facilities described in <xref
|
||||
linkend="custom-implementations" />. As this approach is feasible for
|
||||
linkend="repositories.custom-implementations" />. As this approach is feasible for
|
||||
comprehensive custom functionality, you can achieve the execution of
|
||||
modifying queries that actually only need parameter binding by
|
||||
annotating the query method with <code>@Modifying</code>:</para>
|
||||
@@ -546,20 +546,14 @@ int setFixedFirstnameFor(String firstname, String lastname);</programlisting>
|
||||
</section>
|
||||
|
||||
<section id="specifications">
|
||||
|
||||
|
||||
<title>Specifications</title>
|
||||
|
||||
|
||||
|
||||
<para>JPA 2 introduces a criteria API that can be used to build queries
|
||||
programmatically. Writing a <code>criteria</code> you actually define the
|
||||
where-clause of a query for a domain class. Taking another step back these
|
||||
criteria can be regarded as predicate over the entity that is described by
|
||||
the JPA criteria API constraints.</para>
|
||||
|
||||
|
||||
|
||||
<para>Spring Data JPA takes the concept of a specification from Eric
|
||||
Evans' book "Domain Driven Design", following the same semantics and
|
||||
providing an API to define such
|
||||
@@ -568,14 +562,10 @@ int setFixedFirstnameFor(String firstname, String lastname);</programlisting>
|
||||
the <interfacename>JpaSpecificationExecutor</interfacename>
|
||||
interface:</para>
|
||||
|
||||
|
||||
|
||||
<programlisting language="java">public interface CustomerRepository extends CrudRepository<Customer, Long>, JpaSpecificationExecutor {
|
||||
…
|
||||
}</programlisting>
|
||||
|
||||
|
||||
|
||||
<para>The additional interface carries methods that allow you to execute
|
||||
<interfacename>Specification</interfacename>s in a variety of ways.</para>
|
||||
|
||||
@@ -587,20 +577,14 @@ int setFixedFirstnameFor(String firstname, String lastname);</programlisting>
|
||||
|
||||
<programlisting language="java">List<T> readAll(Specification<T> spec);</programlisting>
|
||||
|
||||
|
||||
|
||||
<para>The <interfacename>Specification</interfacename> interface is as
|
||||
follows:</para>
|
||||
|
||||
|
||||
|
||||
<programlisting language="java">public interface Specification<T> {
|
||||
Predicate toPredicate(Root<T> root, CriteriaQuery<?> query,
|
||||
CriteriaBuilder builder);
|
||||
}</programlisting>
|
||||
|
||||
|
||||
|
||||
<para>Okay, so what is the typical use case?
|
||||
<interfacename>Specification</interfacename>s can easily be used to build
|
||||
an extensible set of predicates on top of an entity that then can be
|
||||
@@ -608,8 +592,6 @@ int setFixedFirstnameFor(String firstname, String lastname);</programlisting>
|
||||
without the need to declare a query (method) for every needed combination.
|
||||
Here's an example:</para>
|
||||
|
||||
|
||||
|
||||
<example>
|
||||
<title>Specifications for a Customer</title>
|
||||
|
||||
@@ -626,7 +608,6 @@ int setFixedFirstnameFor(String firstname, String lastname);</programlisting>
|
||||
};
|
||||
}
|
||||
|
||||
|
||||
public static Specification<Customer> hasSalesOfMoreThan(MontaryAmount value) {
|
||||
return new Specification<Customer>() {
|
||||
Predicate toPredicate(Root<T> root, CriteriaQuery<?> query,
|
||||
@@ -639,8 +620,6 @@ int setFixedFirstnameFor(String firstname, String lastname);</programlisting>
|
||||
}</programlisting>
|
||||
</example>
|
||||
|
||||
|
||||
|
||||
<para>Admittedly the amount of boilerplate leaves room for improvement
|
||||
(that will hopefully be reduced by Java 8 closures) but the client side
|
||||
becomes much nicer as you will see below. Besides that we have expressed
|
||||
@@ -649,16 +628,12 @@ int setFixedFirstnameFor(String firstname, String lastname);</programlisting>
|
||||
might use a <interfacename>Specification</interfacename> as
|
||||
follows:</para>
|
||||
|
||||
|
||||
|
||||
<example>
|
||||
<title>Using a simple Specification</title>
|
||||
|
||||
<programlisting language="java">List<Customer> customers = customerRepository.findAll(isLongTermCustomer());</programlisting>
|
||||
</example>
|
||||
|
||||
|
||||
|
||||
<para>Okay, why not simply create a query for this kind of data access?
|
||||
You're right. Using a single <interfacename>Specification</interfacename>
|
||||
does not gain a lot of benefit over a plain query declaration. The power
|
||||
@@ -668,8 +643,6 @@ int setFixedFirstnameFor(String firstname, String lastname);</programlisting>
|
||||
<classname>Specifications</classname> helper class we provide to build
|
||||
expressions like this:</para>
|
||||
|
||||
|
||||
|
||||
<example>
|
||||
<title>Combined Specifications</title>
|
||||
|
||||
@@ -683,8 +656,6 @@ List<Customer> customers = customerRepository.readAll(
|
||||
<interfacename>Specification</interfacename> implementations and
|
||||
combining them with ones already existing.</para>
|
||||
</example>
|
||||
|
||||
|
||||
</section>
|
||||
|
||||
<section id="transactions">
|
||||
|
||||
Reference in New Issue
Block a user