-
Notifications
You must be signed in to change notification settings - Fork 617
Track state of objects with assigned ids correctly. #2347
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 @LGDOI Are you able to share the classes for Also are you using 6.1.x or 6.0.x? |
Never mind, I could figure out what I needed to reproduce it from your other ticket. |
This change makes the Cypher generator create a statement for persisting multiple instances with assigned ids that not only returns the assigned ID, but also the internally generated id. This id is needed for tracking the root objects state in the `NestedRelationshipProcessingStateMachine`. Those ids must of course be retrieved. By doing so we currently loos the ability to debug log the number of nodes created. While this removal of a log statement can be considered a breaking change, it is necessary. To lighten that change: Storing multiple instances with internally generated did not debug log these informations at all. This fixes #2347.
This change makes the Cypher generator create a statement for persisting multiple instances with assigned ids that not only returns the assigned ID, but also the internally generated id. This id is needed for tracking the root objects state in the `NestedRelationshipProcessingStateMachine`. Those ids must of course be retrieved. By doing so we currently loos the ability to debug log the number of nodes created. While this removal of a log statement can be considered a breaking change, it is necessary. To lighten that change: Storing multiple instances with internally generated did not debug log these informations at all. This fixes #2347.
Hi, @michael-simons, I believe I was on 6.1.3 when I saw this error (99.9%). But 0.1% chance I was on older version as I was switching b/w version to compare the API behavior. Edit: I just realized that you mentioned about |
You're welcome and sorry for any inconvenience. Both reports have been very useful to us. |
I cannot tell if is a bug or a feature.
Given two node classes
Application
andWorkflow
.Application
has outgoing 1-to-many relationship toWorkflow
.Workflow
has incoming relationship toApplication
.The following code causes NPE during
.saveAll
call.Note: if you comment out these two lines setting app1 to wf1 and wf2, NPE won't occur.
Note2: replace
.saveAll(listOf(app1))
with.save(app1)
solves the problem.Note3: this example only shows one app1. but the same NPE happens even if the list size > 1
Stacktrace
Analysis
Neo4jTemplate.processNestedRelations
contains a lambda there is a condition to setrelatedInternalId
on line 746-747.When this condition is
true
,stateMachine.getInternalId(relatedValueToStore);
returnnull
.Question
Should this condition return
false
if thestateMachine
does not have an internal ID forrelatedValueToStore
?The text was updated successfully, but these errors were encountered: