Sounds reasonable đ
Officially the docs say undefined, so please donât rely upon it.
But the defacto standard is consistent.
The model is a directed graph, but when direction does not matter, CYPHER
allows to ignore it.
Are there some cases where adding support for true undirected edges adds value
over the above approach?
> On Jan 25, 2022, at 10:01 AM, Josh Innis <joshin...@gmail.com> wrote:
>
> I have spent some time on the Neo4J console. I was running this set of
> commands:
>
> 1. MERGE ({side: 'left'})-[:edge]-({side:'right'})
> 2. MATCH (l{side: 'left'})-[:edge]->(r{side:'right'}) RETURN l, r
> 3. MATCH (l{side: 'left'})<-[:edge]-(r{side:'right'}) RETURN l, r
> 4. MATCH (n) DETACH DELETE n
>
> No matter how many times I deleted the nodes and ran the merge command:
> Line 2 returns 1 row and line 3 returns 0 rows. Even though the
> documentation says it is ambiguous, for the version freely
> available for what is the defacto standard: this ambiguous query will
> always create relationships going left to right.
>
> On Mon, Jan 24, 2022 at 5:37 PM Josh Innis <josh.in...@bitnine.net> wrote:
>
>> Support in what way, have two edges, one for each direction or what Jasper
>> and Nick are suggesting?
>>
>> On Mon, Jan 24, 2022 at 5:35 PM John Gemignani <john.gemign...@bitnine.net
>>>
>> wrote:
>>
>>> I don't think having a default direction applied for a non-directed edge
>> is
>>> a good idea; there wouldn't be a way to tell these edges apart later on.
>>>
>>> I think it might be a better idea to just support non-directed edges.
>>>
>>> John
>>>
>>> On Mon, Jan 24, 2022 at 3:35 PM Jasper Blues <jas...@liberation-data.com
>>>
>>> wrote:
>>>
>>>> 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.
>>>>
>>>>
>>>
>>
