It was suggested to us to change to SDN6 to be able to use dynamic filtering based on property names in the data layer. However we've come across a problem with optimistic locking, and it feels like a bug.
Basically, our data model is like this:
BaseObject --HAS_VERSION--> BusinessObject
(This is a part of a larger versioning concept, but it is not relevant here.)
Here is a diagram that explains our issue:
Basically, we read a BusinessObject and modify it (step 1).
When we save it in the SDN6 repo (step 2), we can see in the debug log that the object is saved properly in the DB as version 2.
But then SDN walks through the relationships to the BaseObject (which hasn't changed), and then walks back to the BusinessObject (version 1), which is somehow still available. We can see this in a Java debug. Then SDN6 tries to rewrite the BusinessObject, and we get an optimistic locking exception, because BusinessObject v1 doesn't exist any more. In SDN5 we could catch such an issue with the depth parameter, but it has been removed.
This looks like an SDN6 bug, or are we modelling/saving the wrong way?
We hoped to remedy this with the "cascading match" bugfix (Replace path query with cascading matches by meistermeier · Pull Request #2140 · spring-projects/spring-data-neo4j · GitHub), so we built spring-data-neo4j and spring-boot-starter-data-neo4j by hand, but it didn't help.