Upgraded the dependency-plugin.
Configured matrix build for travis, allowing the JDK 11 build to fail.
The failure should go away once the Spring Framework version we use include the fix for SPR-17093.
Removed Jacoco from the build for JDK 10+.
The id-property was used to determine if there is an instance at all, or if it was null.
For entities that don't have an id that purpose is now fulfilled by selecting the backreference and checking it against null.
See also: DATAJDBC-223.
Previously, SimpleJdbcRepository.save(…) returned the original instance as result of the operation. That assumed that the JdbcAggregateOperations would only manipulate that instance, not return a new one. We now properly return the result of the delegating method call.
The entity creation not skips the property population entirely if the metamodel indicates that the instantiation already creates a complete entity. If there's need to actively populate properties, we now correctly skip the ones already consumed by the constructor.
Original pull request: #86.
If a parent DbAction does not offer a generated id, the id of the entity is used instead. This behavior was broken by DATAJDBC-241.
Related tickets: DATAJDBC-241.
Original pull request: #85.
Immutable entities can now be saved and loaded and the immutability will be honored.
This feature is currently limited to a single level of reference.
In order to implement this the logic for updating IDs with those generated from the database got moved out of the DefaultDataAccessStrategy into the AggregateChange.
As part of that move DataAccessStrategy.save now returns a generated id, if available.
See also: DATAJDBC-248.
Slight rewording of individual parts. Include namespace/populator/return type includes. Use spring-framework-docs variable where possible.
Original pull request: #81.
Introduced variable for linking to JavaDoc.
Used the `revnumber` in there in order to link to the proper version of the JavaDoc.
Changed package and class names matching the changes of DATAJDBC-226.
Fixed some typos.
Original pull request: #81.
Also made RelationalMappingContext actually use the JdbcSimpleTypes.
In order for this to work the database needs to be able to handle parameters of type UUID and store them either as such or internally convert them.
Currently no conversion by Spring Data JDBC happens.
Original pull request: #76.
We now no longer import JdbcConfiguration to prevent bean overrides when creating a configuration class that extends JdbcConfiguration. Using EnableJdbcRepositories requires either an import of the configuration class inside the application code or registration of the required RelationalConverter and RelationalMappingContext beans.
Related ticket: DATAJDBC-244
Enhance Javadoc. Fix generics for AggregateChange in JdbcAggregateTemplate. Use Lombok's Data annotation where possible. Typos.
Original pull request: #80.
Note: Immutable entities still aren't supported yet, these are just the API changes plus implementations that work for mutable entities.
The API of DbActions will need further evolution.
Original pull request: #80.
All the methods in JdbcConfiguration are now protected so the class can be extended and the methods overwritten in order to customize the configuration of Spring Data JDBC.
Return List<DbChange<?>> in RelationalEntityWriters so AggregateChange can be assembled in less places to reduce the number of abstractions per method. Change ResultOrException in FunctionCollector to static class so instances no longer retain a reference to their enclosing class. Fix DbAction generics in AggregateChange. Replace simple constructors with Lombok usage. Javadoc, typos, formatting.
Original pull request: #79.
JdbcEntityWriter and JdbcDeleteEntityWriter now use an iterative approach based on PersistentPropertyPath instead of a recursive one.
DbAction is now split into multiple interfaces representing different variants of actions.
The implementations are simple value types without any implementation inheritance hierarchy.
All elements of a DbAction implementation are not null making usage and construction of instances much easier.
Original pull request: #79.
We now support configurable conversion by introducing CustomConversions and RelationalConverter. CustomConversions is a registry for converters that should be applied on a per-type basis for properties. CustomConversions is typically registered as bean and fed into RelationalMappingContext and the newly introduced RelationalConverter to consider simple types and conversion rules.
RelationalConverter with its implementation BasicRelationalConverter encapsulates conversion infrastructure such as EntityInstantiator, CustomConversions, and MappingContext that is required during relational value conversion. BasicRelationalConverter is responsible for simple value conversion and entity instantiation to pull related code together. It's not in full charge of row result to object mapping as this responsibility remains as part of DataAccessStrategy.
This change supersedes and removes ConversionCustomizer.
Jens Schauder
Mark Paluch
Christoph Strobl
Michael J. Simons
Yoichi Imai
Florian Lüdiger
Oliver Gierke
Toshiaki Maki