Relations are not saved correctly [DATAGRAPH-1017]

[spring-projects-issues]

niels opened DATAGRAPH-1017 and commented

Relationsships are not handled correctly. I tried to create an example where I show the behavior of https://stackoverflow.com/questions/44907670/spring-data-rest-with-neo4j-how-to-remove-relationship. Unfortunately I make the experience that the relations wasn't save correctly.
I didn't find a correct example.
I make a branch based von the 4.2.x branch and extended the test-class Neo4jRepositoryIT. So you can see the problem directly

---

Affects: 4.2.6 (Ingalls SR6)

Reference URL: https://github.com/opensource21/spring-data-neo4j/tree/4.2.x-relationBug

Issue Links:

• DATAGRAPH-990 SDN generte query which remove existing relationships during adding new relationships (save node query)
  ("is duplicated by")
• DATAGRAPH-972 Delete relationship not work
  ("is duplicated by")

[spring-projects-issues]

František Hartman commented

Thank you for reporting this.

The issue in the test is that it executes every operation on the repository in a separate transaction (hence separate session) - due to EnableNeo4jRepositories#enableDefaultTransactions is true by default.

Annotated with @Transactional the test works fine.

The actual issue here is that it manages to autowire the Session - it should fail with something like "no active transaction for current thread"

[spring-projects-issues]

niels commented

Hi thank you for analyzing the issue. I don't understand your comment.
In test is an @Transactional or do you mean the in SO-referenced test SocietyApplicationTests? There you are right, the behaviour is fine if I add @Transactional-Annotation. However even without running in one big transaction it should work or fail earlier, specially the test with pure OGM runs with a transaction for each operation

[spring-projects-issues]

František Hartman commented

Yes, I mean the SO-referenced test SocietyApplicationTests.

The OGM one uses one session only - that's why the delete works - you need to perform the load and delete with the same Session - that's how OGM recognizes that a relationship was removed from a collection and should be deleted.

The SDN test case uses default transaction management, so a new session and transaction for each operation (OGM Session is bound a transaction in SDN).

The testCrudOperationsWithRelations test fails because for Collection the default is HashSet and you use id in your equals and hash code (you should depend on other fields that graph id when using hash based collections) - this is my guess, I haven't verified this, but quickly changing to List fixes the test

[spring-projects-issues]

niels commented

Hi Frantisek,

thanks for explaination. Now I understand the behavior (the typical session issues like in hibernate). I added the information at SO. However I still can't change relationship with the @RepositoryRestResource approach. It seems an Open-Session-In-View problem. So the transaction doesn't start with the http-request. Can you be so kindly and give me a hint how to fix it? Ist there a property like spring.jpa.open-in-view?

Regards
Niels

[michael-simons]

The correct solution is stated on Stack Overflow. For Spring Data Rest to work correctly, an Open Session in View interceptor is needed.

The most easiest way to do this is a config like this

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.data.neo4j.web.support.OpenSessionInViewInterceptor;
import org.springframework.web.servlet.handler.MappedInterceptor;

@Configuration
public class MyWebAppConfigurationForSpringDataRest {

	@Bean // <.>
	public OpenSessionInViewInterceptor openSessionInViewInterceptor() {
		return new OpenSessionInViewInterceptor();
	}

	@Bean // <.>
	public MappedInterceptor mappedOSIVInterceptor(OpenSessionInViewInterceptor openSessionInViewInterceptor) {
		return new MappedInterceptor(new String[] { "/**" }, openSessionInViewInterceptor);
	}
}

which is taken straight from the enhanced section of the 5.1.x, 5.2.x and 5.3.x FAQ after the following commits.