Instead of using Map.Entry we now use a dedicated class to hold key and value of a map entry.
This avoids side effects from the implementation of Map.Entry.
Replaced call to saveReferencedEntities with insertReferencedEntities which is simpler but equivalent since referenced entities always get only inserted, never updated.
Removed superfluous methods resulting from that change.
RowMapper can be configured either via the @Query(rowMapperClass = ….) or by registerign a RowMapperMap bean and register RowMapper per method return type.
@Bean
RowMapperMap rowMappers() {
return new ConfigurableRowMapperMap() //
.register(Person.class, new PersonRowMapper()) //
.register(Address.class, new AddressRowMapper());
}
When determining the RowMapper to use for a method the following steps are followed based on the return type of the method:
1. If the type is a simple type no RowMapper is used. Instead the query is expected to return a single row with a single column and a conversion to the return type is applied to that value.
2. The entity classes in the RowMapperMap are iterated until one is found that is a superclass or interface of the return type in question. The RowMapper registered for that class is used. Iterating happens in the order of registration, so make sure to register more general types after specific ones.
If applicable wrapper type like collections or Optional are unwrapped. So a return type of Optional<Person> will use the type Person in the steps above.
The ResultSetParameterValueProvider uses the relevant property for a requested parameter in order to obtain the proper column name to use.
Improved mocking of ResultSets in tests to actually fail when a non existing column gets requested instead of just returning null.
Extracted method to maintain a single level of abstraction.
Added description to assertion that wasn't obvious to me.
Added JavaDoc on existing method.
Commented repository methods in test with issue ids to ease understanding the purpose of each method.
Added @Modify for marking queries that perform DML or DDL.
Modifying queries with return type boolean or Boolean return wether the number of updated rows is greater 0.
This shouldn't be used for DML statements since it will always return false.
Original pull request: ##48.
In the past, Spring Data JDBC performed autoconfiguration such as gleaning whether or not MyBatis is on the classpath, and also whether or not certain other beans exist. This commit removes such flexible settings and instead wires up a JdbcMappingContext seeking an optional NamingStrategy and optional ConversionCustomizer. The other required beans will alert the end user if they don't exist.
All relevant test cases are updated to inject the proper components.
All autoconfiguration is being moved outside Spring Data JDBC, to eventually join Spring Boot after being shook out as an independent module.
Added a property path to DbActions in order to make them aware of the property it is related to.
Then used the JdbcPersistentProperty based on that get the name of the back-reference name of that property back to the root entity of that property.
This gets the NamingStrategy properly involved, as it should.
Instead of using the vanilla PropertyPath a new JdbcPropertyPath is introduced.
It allows for an empty path avoiding various null-checks.
Upgraded SD-Commons dependency to 2.1.x in order to utilise DATACMNS-1199.
Removed the now superfluous PropertyPaths and used PropertyPath methods instead.
Related issues:
DATACMNS-1204
DATACMSN-1199
If the id of an entity is provided as an additional parameter, i.e. the foreign key to an entity is the primary key, no id column is generated in the insert since it gets generated for the additional parameter.
Jens Schauder
Kazuki Shimizu
Greg Turnquist
Tadaya Tsuyukubo
Christoph Strobl
Mark Paluch
sedooe
Michael Simons