-
Notifications
You must be signed in to change notification settings - Fork 165
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
Updates are not saved correctly, depending on the graphId of objects in the database #576
Comments
I added some additional logs. Here are the outputs: Successful run:
Failed run:There is an offset of 20 in the graphIds compared to the successful run
|
Thanks Andy. We’ll investigate this after the holidays. Thanks a lot for the detailed reproducer. The caching of all the things especially around native and non native ids is bugging us all over the place. Also thanks for giving 3.2 a test run. Does it happen with 3.1 as well? |
Yes, the problem also exists in version 3.1.4. As you can see in the fix #576, this is not a caching problem but a problem in the order of processing. |
…same nodes. Co-authored-by: Michael Simons <michael.simons@neo4j.com>
…same nodes. Co-authored-by: Michael Simons <michael.simons@neo4j.com>
…same nodes. Co-authored-by: Michael Simons <michael.simons@neo4j.com>
… same nodes. Co-authored-by: Michael Simons <michael.simons@neo4j.com>
… same nodes. Co-authored-by: Michael Simons <michael.simons@neo4j.com>
… same nodes. Co-authored-by: Michael Simons <michael.simons@neo4j.com>
Resolved in both 3.1.x and 3.2. Expect the next alpha of 3.2 this week. Thanks again for reporting this issue and your contribution. |
The identity map used the wrong map to look up the expected hash value when both a node and relationship with the same id have been loaded and a NPE happened when casting literal Null to long. This has been fixed by first selecting the correct hash. The error first appeared in the performance optimizations in #576, #577 and #579.
The identity map used the wrong map to look up the expected hash value when both a node and relationship with the same id have been loaded and a NPE happened when casting literal Null to long. This has been fixed by first selecting the correct hash. The error first appeared in the performance optimizations in #576, #577 and #579.
The identity map used the wrong map to look up the expected hash value when both a node and relationship with the same id have been loaded and a NPE happened when casting literal Null to long. This has been fixed by first selecting the correct hash. The error first appeared in the performance optimizations in #576, #577 and #579.
Current Behavior
The deletion of a relationship has only 50% success rate according to the starting graphId of newly added objects.
Steps to Reproduce (for bugs)
See test case
I suspect that it has to do with the use of HashMap and HashSet, because due to different graphIds - and thus also the hashCodes - the order in which objects are processed is different.
Your Environment
The text was updated successfully, but these errors were encountered: