SDN6 & @Version

Hey y'all,

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.

Thanks for reporting this. I will have a look at this and give you feedback.

We just found out that there is a problem in combination with immutable entities. Return new instance after incrementing version property on immutables. · Issue #2154 · spring-projects/spring-data-neo4j · GitHub
Is this something that does also apply in your case?

Thanks for getting back so quickly. I have tried the patch for issue 2154, but it did not fix the specific issue above. It did however fix another (simpler) issue with relationships for us where saving didn't work at all.

I'll try to put together a sample project when I find the time. Unfortunately this is all private code. For the moment my team has decided to stay on SDN5.

This brings me to the conclusion that you are using immutable entities, right?

Yes, all entities are immutable using Lombok annotations.