relationship properties and lazy loading

[matt-beanland]

Ash does lazy loading but expects that it will always have any belongs_to relationship source_attribute available on the source resource, so that it can load the related resource. What I've been doing with AshNeo4j up to now (0.2.7) is synthesise this attribute from the relationship, by traversing it (cheap in neo4j). If Ash has a related resource it is trying to hydrate, and it is Ash.NotLoaded, and the belongs_to source id is nil, it will issue a read of the related resource with id in [nil] in order to attempt to load it. So we are bearing the expense of the related node read twice.

Has_one is effectively the same in the reverse direction, and means there is 1:1 relationship, like a belongs_to the other way. In has one the destination has a destination attribute generally named _id, which is the id of the related source.

I think what I'm going to need to do to avoid this double loading is to store these relationships as both edges and properties. When loading I can just read the node, and let ash just read nodes to populate relationships. The edges can still be read which will allow native graph queries. Delete relationships will need to delete the edge and the property. There is a fair bit of work here.

A has_many can have either a an explicit or implicit belongs_to as a reverse relationship.

[matt-beanland]

In ash the forward and reverse relationships are independent. This means we actually need to model independent edges for BELONGS_TO, HAS_MANY and HAS_ONE. These will be directed and should be the default (relate clause should not be needed unless we want to override the relationship name).

Ideally we can avoid needing to store discrete relationship attributes on (for HAS_ONE, HAS_MANY these are a 'destination_attribute', stored on the destination resource pointing back to the the source - default Id property or _id attribute; for BELONGS_TO these are a 'source_attribute' on the source node pointing to the destination id attribute. The attributes must not be in 'skip' on the appropriate resource.

We may be able to use neo4j's 'map projection' concept to synthesise the result map (node) using properties from the destination node, avoiding the need to store these explicitly.

[matt-beanland]

The enhancement independent relationships has extended/simplified the dsl and modified the datalayer to support the functionality, however didn't experiment with 'map projection' cypher (unknown if supported in Boltx responses).