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. >>>> >>>> >>> >>