Re: [DISCUSS] Ambiguity in the MERGE Specification

[Muhammad Shoaib <sh...@apache.org>]

Folks, 

In property graph edges are directional by default unless some property is classified as by directional. like KNOWN because each property can't be unidirectional for example
FATER-OF, SON-OF, HAVE-CHILD these all are properties that cannot be unidirectional therefore, 

My suggestions will be using a type of option in property to allow more clear semantics. These types can be directional, unidirectional or can have inverse-property. 

Ciao, 
MS.  

On 2022/01/24 23:06:13 Josh Innis 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.
>