@ -9,7 +9,7 @@ Events and callbacks get only triggered for aggregate roots.
@@ -9,7 +9,7 @@ Events and callbacks get only triggered for aggregate roots.
If you want to process non-root entities, you need to do that through a listener for the containing aggregate root.
Entity lifecycle events can be costly, and you may notice a change in the performance profile when loading large result sets.
You can disable lifecycle events on the link:{spring-data-jdbc-javadoc}org/springframework/data/jdbc/core/JdbcAggregateTemplate.html#setEntityLifecycleEventsEnabled(boolean)[Template API].
You can disable lifecycle events on javadoc:org.springframework.data.jdbc.core.JdbcAggregateTemplate#setEntityLifecycleEventsEnabled(boolean)[Template API].
For example, the following listener gets invoked before an aggregate gets saved:
@ -46,22 +46,22 @@ The following table describes the available events.For more details about the ex
@@ -46,22 +46,22 @@ The following table describes the available events.For more details about the ex
| Before an aggregate root gets converted into a plan for executing SQL statements, but after the decision was made if the aggregate is new or not, i.e. if an update or an insert is in order.
| After an aggregate root gets created from a database `ResultSet` and all its properties get set.
|===
@ -77,33 +77,33 @@ Spring Data JDBC uses the xref:commons/entity-callbacks.adoc[`EntityCallback` AP
@@ -77,33 +77,33 @@ Spring Data JDBC uses the xref:commons/entity-callbacks.adoc[`EntityCallback` AP
|===
| Process | `EntityCallback` / Process Step | Comment
| This is the correct callback if you want to set an id programmatically. In the previous step new aggregates got detected as such and a Id generated in this step would be used in the following step.
2+| Convert the aggregate to a aggregate change, it is a sequence of SQL statements to be executed against the database. In this step the decision is made if an Id is provided by the aggregate or if the Id is still empty and is expected to be generated by the database.
| Changes made to the aggregate root may get considered, but the decision if an id value will be sent to the database is already made in the previous step.
Do not use this for creating Ids for new aggregates. Use `BeforeConvertCallback` instead.
2+| The SQL statements determined above get executed against the database.
@ -129,7 +129,7 @@ class ApplicationConfig extends AbstractJdbcConfiguration {
@@ -129,7 +129,7 @@ class ApplicationConfig extends AbstractJdbcConfiguration {
----
<1> `@EnableJdbcRepositories` creates implementations for interfaces derived from `Repository`
<2> `AbstractJdbcConfiguration` provides various default beans required by Spring Data JDBC
<2> javadoc:org.springframework.data.jdbc.repository.config.AbstractJdbcConfiguration[] provides various default beans required by Spring Data JDBC
<3> Creates a `DataSource` connecting to a database.
This is required by the following two bean methods.
<4> Creates the `NamedParameterJdbcOperations` used by Spring Data JDBC to access the database.
@ -139,7 +139,7 @@ The configuration class in the preceding example sets up an embedded HSQL databa
@@ -139,7 +139,7 @@ The configuration class in the preceding example sets up an embedded HSQL databa
The `DataSource` is then used to set up `NamedParameterJdbcOperations` and a `TransactionManager`.
We finally activate Spring Data JDBC repositories by using the `@EnableJdbcRepositories`.
If no base package is configured, it uses the package in which the configuration class resides.
Extending `AbstractJdbcConfiguration` ensures various beans get registered.
Extending javadoc:org.springframework.data.jdbc.repository.config.AbstractJdbcConfiguration[] ensures various beans get registered.
Overwriting its methods can be used to customize the setup (see below).
This configuration can be further simplified by using Spring Boot.
@ -152,7 +152,7 @@ There are a couple of things one might want to customize in this setup.
@@ -152,7 +152,7 @@ There are a couple of things one might want to customize in this setup.
== Dialects
Spring Data JDBC uses implementations of the interface `Dialect` to encapsulate behavior that is specific to a database or its JDBC driver.
By default, the `AbstractJdbcConfiguration` attempts to determine the dialect from the database configuration by obtaining a connection and registering the correct `Dialect`.
By default, the javadoc:org.springframework.data.jdbc.repository.config.AbstractJdbcConfiguration[] attempts to determine the dialect from the database configuration by obtaining a connection and registering the correct `Dialect`.
You override `AbstractJdbcConfiguration.jdbcDialect(NamedParameterJdbcOperations)` to customize dialect selection.
If you use a database for which no dialect is available, then your application won’t start up.
@ -161,8 +161,8 @@ Alternatively, you can implement your own `Dialect`.
@@ -161,8 +161,8 @@ Alternatively, you can implement your own `Dialect`.
[TIP]
====
Dialects are resolved by {spring-data-jdbc-javadoc}/org/springframework/data/jdbc/repository/config/DialectResolver.html[`DialectResolver`] from a `JdbcOperations` instance, typically by inspecting `Connection.getMetaData()`.
+ You can let Spring auto-discover your `JdbcDialect` by registering a class that implements `org.springframework.data.jdbc.repository.config.DialectResolver$JdbcDialectProvider` through `META-INF/spring.factories`.
Dialects are resolved by javadoc:org.springframework.data.jdbc.repository.config.DialectResolver[] from a `JdbcOperations` instance, typically by inspecting `Connection.getMetaData()`.
+ You can let Spring auto-discover your javadoc:org.springframework.data.jdbc.core.dialect.JdbcDialect[] by registering a class that implements `org.springframework.data.jdbc.repository.config.DialectResolver$JdbcDialectProvider` through `META-INF/spring.factories`.
`DialectResolver` discovers dialect provider implementations from the class path using Spring's `SpringFactoriesLoader`.
The methods of `CrudRepository` instances are transactional by default.
For reading operations, the transaction configuration `readOnly` flag is set to `true`.
All others are configured with a plain `@Transactional` annotation so that default transaction configuration applies.
For details, see the Javadoc of link:{spring-data-jdbc-javadoc}org/springframework/data/jdbc/repository/support/SimpleJdbcRepository.html[`SimpleJdbcRepository`].
For details, see the Javadoc of javadoc:org.springframework.data.jdbc.repository.support.SimpleJdbcRepository[].
If you need to tweak transaction configuration for one of the methods declared in a repository, redeclare the method in your repository interface, as follows:
By convention, Spring Data applies a `NamingStrategy` to determine table, column, and schema names defaulting to https://en.wikipedia.org/wiki/Snake_case[snake case].
An object property named `firstName` becomes `first_name`.
You can tweak that by providing a {spring-data-jdbc-javadoc}org/springframework/data/relational/core/mapping/NamingStrategy.html[`NamingStrategy`] in your application context.
You can tweak that by providing a javadoc:org.springframework.data.relational.core.mapping.NamingStrategy[] in your application context.
[[entity-persistence.custom-table-name]]
== Override table names
When the table naming strategy does not match your database table names, you can override the table name with the {spring-data-jdbc-javadoc}org/springframework/data/relational/core/mapping/Table.html[`@Table`] annotation.
When the table naming strategy does not match your database table names, you can override the table name with the javadoc:org.springframework.data.relational.core.mapping.Table[] annotation.
The element `value` of this annotation provides the custom table name.
The following example maps the `MyEntity` class to the `CUSTOM_TABLE_NAME` table in the database:
@ -26,7 +26,7 @@ class MyEntity {
@@ -26,7 +26,7 @@ class MyEntity {
[[entity-persistence.custom-column-name]]
== Override column names
When the column naming strategy does not match your database table names, you can override the table name with the {spring-data-jdbc-javadoc}org/springframework/data/relational/core/mapping/Column.html[`@Column`] annotation.
When the column naming strategy does not match your database table names, you can override the table name with the javadoc:org.springframework.data.relational.core.mapping.Column[] annotation.
The element `value` of this annotation provides the custom column name.
The following example maps the `name` property of the `MyEntity` class to the `CUSTOM_COLUMN_NAME` column in the database:
@ -43,7 +43,7 @@ class MyEntity {
@@ -43,7 +43,7 @@ class MyEntity {
ifdef::mapped-collection[]
The {spring-data-jdbc-javadoc}org/springframework/data/relational/core/mapping/MappedCollection.html[`@MappedCollection`]
The javadoc:org.springframework.data.relational.core.mapping.MappedCollection[]
annotation can be used on a reference type (one-to-one relationship) or on Sets, Lists, and Maps (one-to-many relationship).
`idColumn` element of the annotation provides a custom name for the foreign key column referencing the id column in the other table.
In the following example the corresponding table for the `MySubEntity` class has a `NAME` column, and the `CUSTOM_MY_ENTITY_ID_COLUMN_NAME` column of the `MyEntity` id for relationship reasons:
@ -64,7 +64,7 @@ class MySubEntity {
@@ -64,7 +64,7 @@ class MySubEntity {
----
When using `List` and `Map` you must have an additional column for the position of a dataset in the `List` or the key value of the entity in the `Map`.
This additional column name may be customized with the `keyColumn` Element of the {spring-data-jdbc-javadoc}org/springframework/data/relational/core/mapping/MappedCollection.html[`@MappedCollection`] annotation:
This additional column name may be customized with the `keyColumn` Element of the javadoc:org.springframework.data.relational.core.mapping.MappedCollection[] annotation:
Mark Paluch
1 year ago