Closed ma-ku closed 3 weeks ago
Hi @ma-ku thanks for your report.
I have to say, "sorry, you're holding it wrong".
A couple of things:
BugRelationship
) you forgot to annotated it with @RelationshipProperties
. Without that, it won't be recognised as a "entity" (in tick marks, because SDN does not consider those as root entities) holding relationship properties, but only as a normal entity being stored, graph would than look as shown in the picture belowI will push a commit shortly demonstrating that and closing the issue.
The commit will contain two solutions: First, you're fixed solution, storing the related entities separately. I would however recommend you to follow a solution in which you just persist your root aggregate.
OK, you are right if the annotation is missing but I unfortunately stripped this when I removed all the additional annotations such as Lombok and such. The classes are annotated with @Node
and @RelationshipProperties
as expected. So at least on our side it still is not working. Not sure what you are going to commit but I would like to see such an example somewhere working. Actually I believe that this is either a nasty edge case or that we have forgotten something in the config of the classes that makes this fail.
This error occurred after we had introduced the abstract base class for the target nodes as we now wanted to model them as nested containers of items. Before that, we only had one concrete target entity and everything was fine. So I would ask you to double check this particular scenario.
See https://github.com/spring-projects/spring-data-neo4j/commit/7d382862185cdfa9f00a80958391b0b1b516cf93
I will be traveling the next 2 weeks, I would defer this than to @meistermeier next week.
Your test cases did not cover one important aspect; the relationships are still there in the sense that the total number is correct, but the properties stored with the relation get dropped. So we experience a loss of information on entities we do not touch and that is what this ticket was about. So maybe holding it wrong is not entirely correct here but I liked the approach how that was handled as a test case and provided more insight with this ticket. I would have appreciated a bit more communication so I could have clarified this instead of just rejecting it.
Closing this because the changes are merged with the changes from #2906
In our project we have encountered a strange behavior with relations with additional properties when either (a) the target class referenced by the
@TargetNode
is a base class with inheriting classes, (b) or the target class has a back reference to the source node.Both conditions lead to corrupted data when the second relation is stored to the same target node. The diagram below shows the case how data model below should be stored in the database:
This is a simplified set of classes that represents the problem while the actual code is a bit more complex. Also did we remove additional annotations for Lombok away to avoid cluttering the code:
The following simple testcode help reproducing the problem:
The above code only created the correct graph if either the property BugTargetBase in the relationship class is pointing to one of the deriving concrete classes, or if the reverse property relatedBugs in class
BugTargetBase
is deleted. Otherwise the second save operation creates the following graph where only the last saved relation exists and not all three relations as it would be expected.We are using Spring Boot 3.2.1 with the corresponding starter packages but we could also reproduce the behavior with
spring-data-neo4j
version 7.3.0.Question is if that is a bug or how this could be modeled so that we have relationships with properties pointing to nodes that are also pointing back to the other side of the relation.