Polishing.
This commit is contained in:
@@ -16,7 +16,7 @@ See "`xref:repository-query-return-types-reference.adoc[Repository query return
|
||||
[[repositories.nullability.annotations]]
|
||||
== Nullability Annotations
|
||||
|
||||
You can express nullability constraints for repository methods by using {spring-framework-docs}/core.html#null-safety[Spring Framework's nullability annotations].
|
||||
You can express nullability constraints for repository methods by using {spring-framework-docs}/core/null-safety.html[Spring Framework's nullability annotations].
|
||||
They provide a tooling-friendly approach and opt-in `null` checks during runtime, as follows:
|
||||
|
||||
* {spring-framework-javadoc}/org/springframework/lang/NonNullApi.html[`@NonNullApi`]: Used on the package level to declare that the default behavior for parameters and return values is, respectively, neither to accept nor to produce `null` values.
|
||||
|
||||
@@ -439,7 +439,7 @@ The type to which the JSON object is unmarshalled is determined by inspecting th
|
||||
The infrastructure eventually selects the appropriate repository to handle the object that was deserialized.
|
||||
|
||||
To instead use XML to define the data the repositories should be populated with, you can use the `unmarshaller-populator` element.
|
||||
You configure it to use one of the XML marshaller options available in Spring OXM. See the {spring-framework-docs}/data-access.html#oxm[Spring reference documentation] for details.
|
||||
You configure it to use one of the XML marshaller options available in Spring OXM. See the {spring-framework-docs}/data-access/oxm.html[Spring reference documentation] for details.
|
||||
The following example shows how to unmarshall a repository populator with JAXB:
|
||||
|
||||
.Declaring an unmarshalling repository populator (using JAXB)
|
||||
|
||||
@@ -65,7 +65,7 @@ By default, the infrastructure picks up every interface that extends the persist
|
||||
However, you might want more fine-grained control over which interfaces have bean instances created for them.
|
||||
To do so, use filter elements inside the repository declaration.
|
||||
The semantics are exactly equivalent to the elements in Spring's component filters.
|
||||
For details, see the {spring-framework-docs}/core.html#beans-scanning-filters[Spring reference documentation] for these elements.
|
||||
For details, see the {spring-framework-docs}/core/beans/classpath-scanning.html[Spring reference documentation] for these elements.
|
||||
|
||||
For example, to exclude certain interfaces from instantiation as repository beans, you could use the following configuration:
|
||||
|
||||
|
||||
@@ -247,7 +247,7 @@ NOTE: Not all Spring Data modules currently support `Stream<T>` as a return type
|
||||
[[repositories.query-async]]
|
||||
== Asynchronous Query Results
|
||||
|
||||
You can run repository queries asynchronously by using {spring-framework-docs}/integration.html#scheduling[Spring's asynchronous method running capability].
|
||||
You can run repository queries asynchronously by using {spring-framework-docs}/integration/scheduling.html[Spring's asynchronous method running capability].
|
||||
This means the method returns immediately upon invocation while the actual query occurs in a task that has been submitted to a Spring `TaskExecutor`.
|
||||
Asynchronous queries differ from reactive queries and should not be mixed.
|
||||
See the store-specific documentation for more details on reactive support.
|
||||
|
||||
Reference in New Issue
Block a user