Neo4j | Intelligent Question Answering System Based on Movie

You cannot access relationship properties directly via repositories. Those classes are just an encapsulation for properties on relationships and are not meant to represent a "physical" relationship or more a relationship entity. Repositories are for @Node annotated classes solely.

If you want to access and modify the properties of a relationship, you have to fetch the relationship defining entity. A relationship on its own is always represented by its start and end node.

The lately introduced required @Id is for internal purposes only. If you have a special need to persist an id-like property on the relationship, it would be just another property in the @RelationshipProperties annotated class.

I did this in the end using the python library py2neo, and created the cypher query using python

Yes, this is a good illustration of a bug that was fixed in Neo4j 4.2.3, and happens when the label is present in an OPTIONAL MATCH on a previously-bound variable.

From the changelog:

Fixed a bug where an index scan would be used to solve an OPTIONAL MATCH incorrectly.

https://github.com/neo4j/neo4j/wiki/Neo4j-4.2-changelog#423

The workaround until the fix was to remove the redundant label.

We highly recommend staying updated to at least the latest patch for your minor version to avoid known and fixed bugs.

There are a few routes you could go with this. I think you are going to want to leave Postgres as your main Django database and use Neo4j as an accessory DB, not managed by the Django framework. You can do this by using the Neo4j client library similar to this post for interfacing with the graph DB yourself.

To keep Neo4j in sync with the Postgres managed by Django, I think signals are going to be your best friend, specifically the post_save signal. Essentially, anytime that you save a Django model, this signal will fire a function that you can write to use the Neo4j client API to reflect the changes in the graph database.

However, depending on how complex your models are, this is where it can get tricky determining which fields were changed to only update those. I had a similar issue a while back and used this custom Mixin (I cant find the original author but kept this in my notes):

The required procedure is conveniently called "TraverseProc" and allows use of both BFS and DFS.

The file doesn't include the name of the callable, either. Discovered it through search of all my neo4j dependencies with

The method needs to have a public visibility. Otherwise Spring cannot create the needed infrastructure around this (proxy related).

There is a little bit more information around this in the documentation https://docs.spring.io/spring-framework/docs/current/reference/html/data-access.html#transaction-declarative-annotations A few lines under the linked section there is a box

When you use proxies, you should apply the @Transactional annotation only to methods with public visibility. If you do annotate protected, private or package-visible methods with the @Transactional annotation, no error is raised, but the annotated method does not exhibit the configured transactional settings. If you need to annotate non-public methods, consider using AspectJ (described later).

So the part you're missing is how grouping keys work in aggregations. The non-aggregation terms act as the grouping key, providing context for the rows that will be emitted, and for what rows the aggregations are being applied.

Your collect() aggregation has no other terms, so there is no grouping key, and you end up with a single list.

If you want the collect() to apply per session_id, then you need to include the session_id as a non-aggregation term so it can act as a grouping key for the aggregation:

You can ignore the cartesian product warning, since that exact approach is needed in order to create the relationships that form the patterns you need.

As for the multiple relationships, it's possible you may have run the query twice. The second run would have created the duplicate relationships. You could use MERGE instead of CREATE for the relationships, that would ensure that there would be no duplicates.

After a long conversation, I cannot leave this thread without an answer.