This change makes use of the Cypher-DSL dialect capatibilities and uses a String identifier internally for all objects. This will be the `elementId()` on Neo4j 5 and higher and `toString(id())` on Neo4j 4 and lower.
Unless explicitly configured by the user through having `@Id @GeneratedValue long id`, we don’t use the `id()` function anymore. This function has been deprecated in Neo4j 5.
Users are encouraged to use `@Id @GeneratedValue String id` for assigning the element id as object id or using custom unique identifiers or `@Id @GeneratedValue UUID id` or `@Id @GeneratedValue(value = UUIDStringGenerator.class) String id` for UUIDs.
We marked the long ids as deprecated, but don’t have any plans for now to remove them, so that future SDN versions will still be compatible with older Neo4j versions if the data model contains long ids.
We opted for using String’s directly to avoid tons of additional instances and rely on the JVMs excellent String caching capatiblities, thus, the `ElementId` interface - not usable so far anyhow - has been removed without current or planned replacement.
See #2716 and other tickets, closes#2718.
In #2668 storing of relationships has been optimised so that existing relationships are not always refetched. The new query always requires `__relationships__` to be present. In the case of relationships with defined properties, `Neo4jMappingContext#createStatementForRelationshipWithPropertiesBatch` only defines that argument for new relationships, so updating relationships with properties fails.
Closes#2704
It's possible now to also define fields in the relationships
to query for by example.
This commit advances the functionality of the PropertyPathWrapper class
to also cater for the needs of the Predicate created by the example
instance(s).
Closes#2696
Discussed in https://github.com/spring-projects/spring-data-commons/issues/2151 and implemented in https://github.com/spring-projects/spring-data-commons/pull/2787 we can build on top and provide basic support for both imperative and reactive repositories.
The support will be available only on the repository level in the first iteration, think
```java
import java.util.UUID;
import org.springframework.data.domain.ScrollPosition;
import org.springframework.data.domain.Sort;
import org.springframework.data.domain.Window;
import org.springframework.data.neo4j.repository.Neo4jRepository;
public interface ScrollingRepository extends Neo4jRepository<ScrollingEntity, UUID> {
Window<ScrollingEntity> findTop4By(Sort sort, ScrollPosition position);
}
```
and other derived finder methods that have a limit and a stable sort.
If requested, further support can be added to the templates, too.
Closes#2691.
Previously relationship related properties in the query method were
missing in the MATCH part but the condition would get applied.
This created an incorrect query string and failed on the server side.
Non-invasive change to avoid regression in the other parts.
Closes#2685
Relying on equals/hashCode in the domain entity can lead into situations
where a existing object cannot found anymore because its hashCode value
has changed. e.g. generated id or version attribute.
Using the raw `System.identityHashCode` solves this problem.
This code also simplifies the overall usage of caching properties and
reduces the storage of object references into one central place.
Closes#2683
Currently we only have the literals clause to render an arbitrary string into a custom Cypher statement.
Although one could prepare the string upfront manually and joining multiple strings on | or &
and pass this to the query method, it would be more convenient to add one or two functions directly.
Namely those functions will be
anyOf : renders input ["a","b", ..] to A|B|..
allOf : renders input ["a","b", ..] to A&B&..
The usage would be MATCH (n::#{allOf(#labels)}) RETURN n, for example.
Closes#2681
Migrate to newly introduced constructors and methods to consider the relationship between the domain type and Class<?> parameters to distinguish between projection parameters and bindable class parameters.
Closes#2671
This is unnecessary because the property itself won't exist in this case,
but only id(node).
More visible now because Neo4j 5+ logs unknown property querying.
Closes#2669
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.
