neo4j / sdn-rx

Nextgen Spring Data module for Neo4j supporting (not only) reactive data access and immutable support
https://neo4j.github.io/sdn-rx
Apache License 2.0
65 stars 23 forks source link

No mechanism is found to control the depth of load and save of data without custom queries. #217

Closed aaramg closed 4 years ago

aaramg commented 4 years ago

I could not find a mechanism to configure the depths when specifying the @Node class and its @Relationships.

  1. If there are self relationships
  2. If there are a lot of other @Relationships to other Nodes and then they have relationships to other nodes etc., in a very long way.

I could not find a way to config what to save and what not and also what to load and what not within the object.

michael-simons commented 4 years ago

Hello @aaramg,

this is correct and intented behaviour.

This is our principle:

Map the subgraphs from your graph that you need, not the whole graph. It is not the point of an Object Mapping framework to reassamble the whole database, neither for a Graph database, nor for a relation database.

In the relational word and with JPA, people do the same and try to solve the issue with eager vs lazy loading and these days, with fetch graphs. With Neo4j-OGM you can control the fetch depth.

The underlying issue is the same in both cases: The whole scheme is mapped and all use cases use the same one.

Think of your domain object and mapping as fetch graph: Map what you need for your use case and not everything.

It is also ok to map an exemplary User node from two perspectives: A ProspectUser and SignedUpUser for example, having different attributes, relationships and maybe also labels. This is also a neat use case for Projections (See https://github.com/neo4j/sdn-rx/blob/master/spring-data-neo4j-rx/src/test/java/org/neo4j/springframework/data/integration/imperative/ProjectionIT.java, we are working on the docs for this atm (https://github.com/neo4j/sdn-rx/pull/207))

This way, your control the depth via your domain model and not some arbitrary settings.

Last but not least: We made it simple to fall back to both custom mappings and queries so that you are in full control and not some magical mapping.