spring-data-neo4j | Provide support to increase developer productivity | Application Framework library

You should not use Spring Data Neo4j R/X anymore. It was a WIP project that eventually finds its destination as the successor of Spring Data Neo4j 5.x (and before). With a recent Spring Boot release (starting with 2.4), you will get the completely rewritten Spring Data Neo4j if you add the Spring Data Neo4j Boot starter to your dependencies:

There is nothing wrong with your mapping / model The problem is in the version of Neo4j you are using. It has a query planner bug. I do not know when it appeared but it is solved with 4.3.3 / 4.2.10 and higher.

This combined with some needed query improvements in SDN 6.1.6 lead to the problematic constellation right now. I would suggest to manually set the Spring Data Neo4j version down to 6.1.5 if you cannot upgrade the database.

It is possible that you are mixing the earlier neo4j-ogm with the latest Spring Data Neo4j

Check your dependencies and make sure your annotations are from the correct packages (for instance, org.springframework.data.neo4j.*)

If you follow the instructions in the link above, you should be able to resolve your errors.

Neo4j OGM 3.2 requires at least Neo4j 3.5.x (as you can see here), but you're using Neo4j 3.0.x. Note: the latest OGM version is 3.2.21.

Due to the inheritance with the BasicNode there was a bug in Spring Data Neo4j that took the wrong meta-information and in your case did not create the right type (SidebarBox). An update will be available later this month. In the mean-time you could check the 6.0.6-SNAPSHOT version of SDN. I created an example with your code https://github.com/meistermeier/neo4j-issues-examples/tree/master/relatedIdQuery And using this very version, it works with List findAllByPerson_Id(Long personId)

For the upcoming 6.1 release we have planned to introduce a "find by object" to also give you more flexibility.

The problem with your setting is that the InformationMutable declares a generic field that is seen by SDN as any other legit @Node annotated entity. As a consequence SDN wants to create something like

Starting with Spring Data Neo4j 6, relationship cannot be top-level entities anymore.

As a consequence, your repository methods must return Skill, SomeCollection (where SomeCollection can be a List, Set, Flux, Page etc). You can also return projections based on Skill, but not @RelationshipProperties-annotated classes.

There used to be some support for this kind of scenario a long time ago (around Spring Data Neo4j 3), but it appears to be very complex to properly support, which is why there is no built-in support for partial entities anymore.

For instance, how do you roll back a transaction if part of the entity is properly persisted (to datastore A) and the other is not (to datastore B)? What if the rollback fails?

If you still want to go down that route, I think you'd need to explicitly use Neo4jTransactionManager and MongoTransactionManager (or their reactive variants) and rely on JTA or similar to coordinate the separate transactions.

For your entities, I would assume that moving away from the Spring Data Commons annotations and using the datastore-specific annotations could work.

There is no custom depth anymore in SDN. It either loads everything that is described in your Java model or you have to supply custom Cypher statements.

Some background for this: with SDN 6 we dropped the internal session cache completely because we want to ensure that the Java object graph is after loading and persisting in sync with the database graph. As a consequence we cannot track a custom depth over multiple operations anymore. A partial loaded graph now reflects the truth of the Java model and when getting persisted might remove existing (but not loaded) relationships.

Some insights can be found in the documentation section for the query creation. https://docs.spring.io/spring-data/neo4j/docs/current/reference/html/#query-creation