Hi All,
The quirk behind that CYPHER comes from Neo4j’s property graph model:
All edges have a direction
When direction is not relevant it can be ignored.
This works will for read queries, for merge it is slightly quirky, however I
believe the specification is reasonable:
If we MERGE with an edge that does not specify a direction, it is because
direction is irrelevant, just as in the read scenario
Given this, the result is to intentionally assign a random direction
I think the above behavior is OK. It would also be reasonable to pick a
consistent direction, however this leads to potential compatibility issues:
Users might start depending on an ‘implied’ direction
When porting to/from Neo4j (interoperability is a strength - being able to
attract users to the platform and have the users be confident they can migrate
if ever they want aids adoption).
So my 2c: Do what Neo4j does, and make it random, because the intention is
“direction doesn’t matter”. However choosing a direction would also be ok. I
don’t think rejecting the MERGE is great, because it differs from how other
CYPHER graph DBs behave.
> On Jan 25, 2022, at 7:06 AM, Josh Innis <josh.in...@bitnine.net> wrote:
>
> Hi All,
>
> The openCypher specification for MERGE has an ambiguous specification on
> the subject of undirected relationships.
>
> Per the document on page 119 in the section titled "Merge on an undirected
> relationship":
>
> MERGE can also be used with an undirected relationship. When it needs to
> create a new one, it will pick a direction.
>
> Query:
> MATCH (charlie:Person {name: 'Charlie Sheen'}), (oliver:Person {name:
> 'Oliver Stone'})
> MERGE (charlie)-[r:KNOWS]-(oliver)
> RETURN r
>
> As 'Charlie Sheen' and 'Oliver Stone' do not know each other, this MERGE
> query will create a KNOWS relationship between them. The direction of the
> created relationship is arbitrary.
>
> We should probably clarify that. Having MERGE use undirected edges to find
> paths is a potentially useful feature, but "The direction of the created
> relationship is arbitrary" is unclear and should be clarified.
>
> I believe there are two potential ways to solve this issue:
> Option 1: Do not let MERGE use undirected edges.
> Option 2: Have a default direction that AGE will use every time MERGE
> creates an edge where direction is not specified.
>
> Personally, I lean towards proposal 2 with the default direction being a
> right directed edge. The other way limits functionality, and as long as the
> decision we make is expressed well in the documentation, I don't believe it
> is too confusing.
>
> Please let us know what you think.
