Skip to content

Custom generated ID for relationships not supported? #2497

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
nioertel opened this issue Mar 14, 2022 · 7 comments
Closed

Custom generated ID for relationships not supported? #2497

nioertel opened this issue Mar 14, 2022 · 7 comments

Comments

@nioertel
Copy link

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.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Mar 14, 2022
@michael-simons
Copy link
Collaborator

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.

@michael-simons michael-simons added blocked: awaiting feedback and removed status: waiting-for-triage An issue we've not yet triaged labels Mar 14, 2022
@nioertel
Copy link
Author

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

@nioertel
Copy link
Author

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
Copy link
Collaborator

  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
Copy link
Author

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
Copy link
Collaborator

Very welcome, thank you for your feedback.

Please note: #2499

We have a callback system in place anyway.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants