SDN supports derived queries over several, deeply nested properties in the following version combinations:
- Spring Data Kay SR9 + Neo4j-OGM 3.0.4
- Spring Data Lovelace RC1 + Neo4j-OGM 3.1.1
As of writing, Spring Boot 2.0.4 picks up Spring Data Kay SR9 + Neo4j-OGM 3.1.0. This is an unsupported combination, see https://github.com/spring-projects/spring-boot/issues/13999.
This tests asserts the correct versions for Spring Boot 2.1.0+ and 2.0.5+. Also fixes the use of final field relationships in the domain classes used in the test and removed the usage of deprecated API.
With JDK 11 ApplicationListeners implemented as lambdas don't get correctly handled at the moment.
This is fixed for Spring Framework 5.0.9, which isn't released yet.
Therefore we depend for the JDBC examples on the snapshot.
An alternative would be to use proper classes instead of lambdas.
See also: SPR-17093.
If properties are final they need to have a matching argument in the persistence constructor or a matching "Wither".
Otherwise trying to set them results in an exception.
Id Properties additionally need a Wither if a generated Id from the database is supposed to get set.
If properties are final they need to have a matching argument in the persistence constructor or a matching "Wither".
Otherwise trying to set them results in an exception.
Upgrade from Lovelace M3 to Lovelace RC1 for examples requiring Lovelace. Upgrade to latest stable MongoDB drivers. Adapt to API changes. Un-pin examples that were previously bound to Spring Data Kay.
Removed the explicit activation of the JDK specific profile activation in the Travis config file in favor of a simple <activation /> element in the POM.
Use blocking queue for imperative synchronization to not depend on the actual machine timing. Refactor reactive API example to use StepVerifier.
Reuse embedded MongoDB utility.
Simplify Customer type using Lombok. Move test code from GridFsApplication to GridFsTests. Split tests into methods. Remove superfluous files.
Original pull request: #229.
Sometimes, e.g. for analytics, it is handy to be able to return a different entity result type from a Repository query method than the base Repository entity type or an interface based projection.
This demonstrates how to use a custom @SqlResultSetMapping in combination with @ColumnResult introduced in JPA 2.1.
