This allows to use Dto based projections to be used in a nested fashion when using the fluent save operations.
This does not solve - or attempt to solve - the issue that we don’t have any information what concrete projection class to be used when projection in all cases.
In the test `nestedProjectWithFluentOpsShouldWork` we could argue that the concrete value can be used to determine the type information. However, while that can be made to work with heterogeneous collections, it would bring a big performance penalty, getting new persistent entity instances and property accessors all the time.
Thus, this change now makes sure no exception is thrown when using such inherited projections, but does explicitly not bring support for deriving the projected properties from them accross an inheritance hierachy.
For more information, please read the comments in org.springframework.data.neo4j.integration.imperative.ProjectionIT#nestedProjectWithFluentOpsShouldWork and org.springframework.data.neo4j.integration.imperative.ProjectionIT#nestedProjectWithFluentOpsShouldWork2.
This closes#2621.
There was a random picking of correct property paths
if they represented the very same length (1).
Added a `isEntity` filter to be sure that only the interesting
property paths get returned.
Closes#2661
This slipped through the check before:
A has dependency on A defined within the constructor.
Because of a "same" entity check, we skipped the `inCreation` check
and did not throw the MappingException.
Closes#2622
If multiple base class extending entities contain the very same target,
it was reported as a cycle.
Now it will get correctly detected as a directed graph.
Closes#2655
This change introduces the concept of `PersistentPropertyCharacteristics` and `PersistentPropertyCharacteristicsProvider`.
The latter can be registered implicitly as a `@Bean` with the mapping context or via a custom mapping context. It allows
checking the properties and their owner for indicators like type and so on to treat them as transient or read only.
Examples have been added to the `Neo4jMappingContextTest` and `PersistentPropertyCharacteristicsIT`.
This closes#2640.
We can support many more usecases of "I want to have a lightweight mapping tool" for DTOs by just
restricting the cases in which a `NoRootNodeMappingException` is thrown.
The idea is as follows: If the `DefaultNeo4jEntityConverter` does not deal with a synthesized
record comming from `AggregatingMappingFunction` it uses the the root map as base for mapping
if the root record is already a map value. If that is not the case and the root record does
not contain any paths that maybe aggregated later one, we synthesize a map one single time
and evaluate that for being mappable.
Closes#2633.
This fixes#2572 and is a tough call: The query presented there is totally valid but returns not an empty result but a record containing only one `null` element due to the way the Cyper `OPTIONAL` keyword works. We could try parsing the query, but this will be an endless rabbit whole in the future to come.
The approach here is to check now whether a result contains exactly one record with one `NULL` value. If that is the case, no exception is thrown but `null` returned, which is later filtered on the clients.
That however drops the checking for non-null values there, so that methods don’t throw in those cases but returns empty optionals or empty / smaller lists.
Especially pull up the parts explaining the differences between SDN6 and SDN+OGM, make the FAQ more visible and have only one appendix in one place.
Closes#2562.
