-
Notifications
You must be signed in to change notification settings - Fork 616
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
Comments
Hi Niels. 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, |
Hi Michael, that actually sounds great and relaxes our Spring Boot upgrade a bit.
Or do we have to completely stick to spring-data Neumann then? Thanks, |
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: and the updated properties Please let me know if you need anything else. |
Thanks for the details. According to the spring-data-releasetrain Neumann-SR9 pom, this is SDN 5.3.9.RELEASE. I will try this setup out. We're not using any other spring-data modules, so there should be no side effects. From the top of my head I found the following breaking changes that will cause major efforts to migrate our project:
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. |
|
Thanks. We can close the issue. Thanks again for your quick support :) |
Very welcome, thank you for your feedback. Please note: #2499 We have a callback system in place anyway. |
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:
This error is expected as the documentation states:
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.
The text was updated successfully, but these errors were encountered: