Or to be fair: The spec itself _is_ ambiguous, however we should also consider
and adhere defacto standards, I think, unless there’s a very strong reason not
to.
> On Jan 25, 2022, at 9:12 AM, Nicholas Sorrell <n...@cint.io> wrote:
>
> I agree with Jasper's response. My preferences would also be the same order:
> Try to keep it arbitrary/random, else pick a direction. Option 1 of rejecting
> the statement deviates from the spec and creates interoperability issues.
>
> ________________________________
> From: Jasper Blues <jas...@liberation-data.com>
> Sent: Monday, January 24, 2022 6:35 PM
> To: dev@age.apache.org <dev@age.apache.org>
> Subject: Re: [DISCUSS] Ambiguity in the MERGE Specification
>
> 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.
>
