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
GH-2201 - Allow interfaces in domain model hierachies.
While technically possible, Spring Data Neo4j prevented a proper use of
interfaces in domain hierachies due to the fact that it checks whether a
primary label has been used already in a domain model. That check can be
triggered at different point in times: Either when initializing the
persistence context with a predefined set of entities or when an
interface based entity is refered from an implementation of itself.
This commit changes the following approaches:
* Interfaces won't contribute to the index of entities by primary label
* The explicit or implicit names of interfaces implemented by an entity
will contribute to the list of additional labels. However, we don't
traverse the graph of interfaces to the top
* When hydrating instances we must check whether the target is an
interface. If so, we go through the list of all known persistent
entities and look for one that can be assigned to the interface and
which spots all the mapped labels
In addition we fixed some bugs when selecting the target entity type
when saving relationships. Also, `@Relationship` without a given
relationship type name will work now without messing up the type name.
This allows for the following scenarios:
1. Creating an API module being free of Spring or Neo4j based
annotations. That API module can than be implemented by different
Spring Data stores that support interfaces in their hierachies like
we do now then.
2. Putting an explicit `@Node` annotation onto an interface so that the
implementation can be arbitrary named (Which is probably a rarer use
case).
3. Using polymorpmic relationships: If an interface has multiple
implementations in the same project, the interface and it's
implementations can both be annotated. The annotation on the
interface is going to be the primary label and the labels on the
annotated implementations are the selectors for picking out the class
to hydrate during loading.
This closes#2201.
Copy file name to clipboardExpand all lines: src/main/asciidoc/object-mapping/mapping.adoc
+45
Original file line number
Diff line number
Diff line change
@@ -74,12 +74,57 @@ The primary label should always be the most concrete label that reflects your do
74
74
For each instance of an annotated class that is written through a repository or through the Neo4j template, one node in the graph with at least the primary label will be written.
75
75
Vice versa, all nodes with the primary label will be mapped to the instances of the annotated class.
76
76
77
+
==== A note on class hierarchies
78
+
77
79
The `@Node` annotation is not inherited from super-types and interfaces.
78
80
You can however annotate your domain classes individually at every inheritance level.
79
81
This allows polymorphic queries: You can pass in base or intermediate classes and retrieve the correct, concrete instance for your nodes.
80
82
This is only supported for abstract bases annotated with `@Node`.
81
83
The labels defined on such a class will be used as additional labels together with the labels of the concrete implementations.
82
84
85
+
We also support interfaces in domain-class-hierarchies for some scenarios:
86
+
87
+
.Domain model in a separate module, same primary label like the interface name
0 commit comments