You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: src/main/asciidoc/appendix/query-creation.adoc
+8-1Lines changed: 8 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -38,7 +38,7 @@ A save operation call in general issues multiple statements against the database
38
38
. For the next defined relationship on the root entity start with 2. but replace _first_ with _next_.
39
39
40
40
41
-
NOTE: As you can see SDN does its best to keep your graph model in sync with the Java world.
41
+
WARNING: As you can see SDN does its best to keep your graph model in sync with the Java world.
42
42
This is one of the reasons why we really advise you to not load, manipulate and save sub-graphs as this might cause relationships to get removed from the database.
43
43
44
44
=== Multiple entities
@@ -84,3 +84,10 @@ The above return part will then look like:
84
84
85
85
The map projection and pattern comprehension used by SDN ensures that only the properties and relationships you have defined are getting queried.
86
86
87
+
In cases where you have self-referencing nodes or creating schemas that potentially lead to cycles in the data that gets returned,
88
+
SDN falls back to a path-based query creation that does a wildcard mapping on all available relationship types reachable from
Copy file name to clipboardExpand all lines: src/main/asciidoc/object-mapping/mapping.adoc
+11-8Lines changed: 11 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -133,15 +133,15 @@ The `type` or the `value` attribute allow configuration of the relationship's ty
133
133
The default direction in SDN is `Relationship.Direction#OUTGOING`.
134
134
135
135
We support dynamic relationships.
136
-
Dynamic relationships are represented as a `Map<String, AnnotatedDomainClass>`.
136
+
Dynamic relationships are represented as a `Map<String, AnnotatedDomainClass>` or `Map<Enum, AnnotatedDomainClass>`.
137
137
In such a case, the type of the relationship to the other domain class is given by the maps key and must not be configured through the `@Relationship`.
138
138
139
139
==== Map relationship properties
140
140
141
141
Neo4j supports defining properties not only on nodes but also on relationships.
142
142
To express those properties in the model SDN provides `@RelationshipProperties` to be applied on a simple Java class.
143
-
144
-
In the entity class the relationship can be modelled as before but its type has to be a `Map` with the related node as the key and the relation property class as value.
143
+
Within the properties class there have to be exactly one field marked as `@TargetNode` to define the entity the relationship points towards.
144
+
Or, in an `INCOMING` relationship context, is coming from.
145
145
146
146
A relationship property class and its usage may look like this:
In general there is no limitation of relationships / hops for creating the queries.
163
163
SDN parses the whole reachable graph from your modelled nodes.
164
-
It is possible to have self-referencing entities and self-referencing concrete instances.
165
164
166
-
If these entities or instances for a cycle we have a strict limit of *2* repetitions of walking the same path through the graph.
167
-
E.g. You model a social network of `(:Person)-[:HAS_FRIEND]->(:Person)-[:HAS_FRIEND]...` you will only get the friends of the second degree.
168
-
If you need a more specific mapping for your domain we advise you to use custom queries.
165
+
This said, when there is the idea of mapping a relationship bidirectional, meaning you define the relationship on both ends of your entity,
166
+
you might do not only get what you are expecting.
167
+
168
+
Consider an example where a _movie_ has _actors_, and you want to fetch a certain movie with all its actors.
169
+
This won't be problematical if the relationship from _movie_ to _actor_ were just unidirectional.
170
+
In a bidirectional scenario SDN would fetch the particular _movie_, its _actors_ but also the other movies defined for this _actor_ per definition of the relationship.
171
+
In the worst case, this will cascade to fetching the whole graph for a single entity.
0 commit comments