Relationship properties #4
Replies: 1 comment
-
Some middle ground would be to extend the dsl so that label defaults to be a node label, but can be an edge label. We'd then store the resource instance as a relationship, with relationship properties, such that:
In the database, we store Ash would require us to have a 'primary key' attribute on the resource, although it is strictly not necessary, but this would allow us to find the relationship by the id. Relationships don't have labels, but again we might need one. From the perspective of the source and destination resource there is a 'connector' resource, with attributes. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
In graph database both Nodes and Relationships are first order concepts. Relationships relate exactly two nodes, and may have properties, otherwise like node properties. However there is an impedance mismatch with Ash, as in Ash relationships are not first order like Resources.
For example if we have Ash Resources Place and Service, and we may initially want to model/storel:
(Place) -[LOCATES:]-> (Service)
however we may want to model not just that Place LOCATES a Service, but exactly how the Place LOCATES the service. Clearly properties that relate to the Place (e.g. type, address, location_id, etc) are stored on the Place, but what the Place means to the Service should be stored on the relationship, for example, the role of the Place to the Service:
(Place) -[LOCATES: {role: 'customerPremises'}]-> (Service)
The place might be a hinterland, the location of a service edge, a local exchange or the customer (UNI). There might also be other properties. In Ash this is hard to model, and is usually done with a 'connector' Resource, we'll call this one a PlaceRef, and we connect Service - PlaceRef - Place. This of course makes our Ash more complex, as the PlaceRef must be explicitly created referencing the Service and Place as each PlaceRef must have a belongs_to relationship with both Place and Service and cannot exist independently.
The simple (and initial) approach for ash_neo4j is to ignore relationship characteristics but support the above pattern, so that in Neo4j we actually store:
(Place) <-[BELONGS_TO]- (PlaceRef {role: 'customerPremises') -[BELONGS_TO]-> (Service)
Clearly this is an extra traversal and isn't as natural and readable. We also would want to support relationship properties so we can read/write existing graph data. This discussion is about how to support relationship properties more fully.
Beta Was this translation helpful? Give feedback.
All reactions