WIP: Add multi-hop support to RelationshipDefinition #635

AntonLydike · 2022-08-13T12:56:25Z

I want to add support for multiple-hop relationship definitions. For example:

class Person(StructuredNode):
  name = StringProperty()
  
  parent = RelationshipTo('Person', 'PARENT')
  ancenstors = RelationshipTo('Person', 'PARENT', n_hops='*')
  decendants = RelationshipFrom('Person', 'PARENT', n_hops='*')
  grandchildren = RelationshipFrom('Person', 'PARENT', n_hops=2)
  # it should also support ranges such as '2..4' or '1..' (one or more)

I am open for ideas and pointers!

AntonLydike · 2022-08-13T14:09:35Z

Question: How to best handle calls to connect(), disconnect(), reconnect(), etc?

I have added a property called allows_creation which marks if this relationship manager is allowed to create edges. The code then checks for this whenever necessary, and if it isn't allowed to create an edge, it throws a NotImplementedError (this type is probably improvable!)

The intended behavior for disconnect and disconnect_all is now to delete the whole path. I am unsure if it is desirable to have such a foot gun though.

AntonLydike · 2022-08-13T14:14:34Z

The allows_creation property could then be used to make re-implementing #533 way easier as this ran into similar issues back then.

aanastasiou · 2023-05-22T12:42:55Z

@AntonLydike

A few thoughts in no particular order:

You propose a Relationship type that can include more than one edges.
In a typical Neo4j database, the underlying property graph is assumed to be a Multigraph. The only thing that Multigraphs add is the ability to have more than one edge between any two nodes.
A Relationship that spans more than one nodes is akin to a hyper-edge in a hypergraph.
A neomodel Relationship does not have hyper-edge semantics.
While it is possible to model hyper-edges in Neo4j, I would be hesitant in trying to lump hyper-edges with Relationships.
- For example, Neo4j includes the concept of a path but that is not a primitive data type throughout CYPHER. Node connections (from the point of view of a data type) are still assumed to be edges with properties that link always two nodes.
- Furthermore, the example you provide here assumes that all segments of a hyper-edge (all the "hops" of a "Relationship") are supposed to have the same property model (the same Relationship class definition). This is not always the case. A hyper-edge with properties can have different attributes at its segments. It is an entirely different data type.

Therefore, I would like to propose the following:

Neomodel could include a contrib entity to model hyper-edges. This entity would have to be a new type. This new type could possibly inherit from Relationship but also include all the functionality that is required of hyper-edges.
To decide what functionality should be assigned to hyper-edges, you should have one or more motivating use-cases.
- Here for example, your motivating use case seems to be being able to address a set of nodes with specific characteristics given a starting node. In my mind, this still sounds like it would be better served via a query. But you may have come across a use-case that indicates otherwise. We need to see the use-cases and the examples before setting off to incorporate this in neomodel.

My perception is that this feature needs more thinking before we can consider a PR, but I am happy to think twice :)