Custom generated ID for relationships not supported?

[nioertel]

We're currently upgrading our application from Spring Boot 2.3.9 to 2.6.4 which means upgrade from SDN 5.3.7 + OGM 3.2.20 to SDN 6.2.2.

In our graph model relationships are a first class citizen with rich relationship entities throughout the graph. Some relationships also need to be uniquely identified outside of our system so we give them a custom generated UUID on creation and basically treat them the same way as nodes on the metadata level (createdOn/By, modifiedOn/By, versioning).

SDN 6.2.2 throws the following exception with this setup:

java.lang.IllegalStateException: The class `com.example.MyRel` for the properties of a relationship is missing a property for the generated, internal ID (`@Id @GeneratedValue Long id`) which is needed for safely updating properties.

This error is expected as the documentation states:

You must define a property for the generated, internal ID (@RelationshipId) so that SDN can determine
during save which relationships can be safely overwritten without losing properties. If SDN does not
find a field for storing the internal node id, it will fail during startup.

I was wondering if this restriction was introduced on purpose and if there are any thoughts on loosening it so we can provide a custom generatorClass also for relationships.
Our domain model is quite big and relationships as well as nodes are inheriting from the same base class that implements everything around auditing, locking and ID generation. I would like to avoid this refactoring if possible.

[michael-simons]

Hi Niels.
Yes this restriction is done on purpose to track the state of relationships. No plans to change it as of now.
if you don't want to migrate, SDN 5.3 Neumann-SR9 still works (tested) with Spring Boot 2.6.4:

https://github.com/michael-simons/neo4j-from-the-jvm-ecosystem/tree/master/spring-boot26-with-sdn-ogm

We still maintain Neo4j-OGM, which is the driving force behind SDN 5.3 anyway, latest release with a tons of improvement regarding memory usage came out last week.

If you don't need reactive, feel free to stick to it.

Cheers,
Michael.

[nioertel]

Hi Michael,

that actually sounds great and relaxes our Spring Boot upgrade a bit.
So the setup would then be:

• spring-data 2021.1.2
• spring-data-neo4j 5.3.9.RELEASE
• neo4j-ogm 3.2.31

Or do we have to completely stick to spring-data Neumann then?

Thanks,
Niels

[michael-simons]

5.3.9 is Neumann-SR2.

I always use the release train https://github.com/michael-simons/neo4j-from-the-jvm-ecosystem/blob/41e0fded281a71758263d1924a85eede72e00f70/spring-boot26-with-sdn-ogm/pom.xml#L21 so that I don't have to manage the Spring Data Commons manually.

Here are the other important bits:

https://github.com/michael-simons/neo4j-from-the-jvm-ecosystem/blob/41e0fded281a71758263d1924a85eede72e00f70/spring-boot26-with-sdn-ogm/src/main/java/org/neo4j/examples/jvm/spring/data/imperative/Application.java#L8

https://github.com/michael-simons/neo4j-from-the-jvm-ecosystem/blob/41e0fded281a71758263d1924a85eede72e00f70/spring-boot26-with-sdn-ogm/src/main/java/org/neo4j/examples/jvm/spring/data/imperative/support/Neo4jOGMConfig.java#L27

and the updated properties

https://github.com/michael-simons/neo4j-from-the-jvm-ecosystem/blob/41e0fded281a71758263d1924a85eede72e00f70/spring-boot26-with-sdn-ogm/src/main/resources/application.properties#L1-L3

Please let me know if you need anything else.

[nioertel]

Thanks for the details.

According to the spring-data-releasetrain Neumann-SR9 pom, this is SDN 5.3.9.RELEASE.
So if I understand your example setup correctly, this means we are bound to spring-data-commons 2.3.9.RELEASE as long as we don't want to upgrade to SDN 6.

I will try this setup out. We're not using any other spring-data modules, so there should be no side effects.
However spring-data-neumann reached EOL just last month - so we need a long term solution soon.

From the top of my head I found the following breaking changes that will cause major efforts to migrate our project:

1. Releationship ID handling means we need to implement a work around for
2. Rich relationship entities don't map the start+end node anymore but just the other end, which means we need to duplicate them all and use the respective type depending into which node we inject them using @Relationship
3. No @PostLoad means we need to rework transient attribute enrichments
4. Missing @Depth for DAO methods causes huge refactoring efforts across the code especially for persist operations

Are any of these planned to be reintroduced? Especially points 2 and 4 would be amazing and I'm not sure why they would be a problem in a reactive setup.

[michael-simons]

1. and 2: No changes planed here.
2. I'm happy to reintroduce this as a feature
3. We suggest having a look at projections. They make depth explicit both on load and save. No plans on depth.

[nioertel]

Thanks.
I had a look at projections and they can be used to solve the issue but it means major refactoring effort for us.
Anyway for now we will stick to SDN Neumann. I will get back to you when we approach the upgrade to SDN 6.

We can close the issue. Thanks again for your quick support :)

[michael-simons]

Very welcome, thank you for your feedback.

Please note: #2499

We have a callback system in place anyway.