I'm not sure of the consequences of storing both directions (like multiple edges returned from a match when there is really only one) for just one non-directional edge. Although, a non-directional edge is technically, bidirectional.
The ideal way would be to support a non-directional edge alongside the other directions. Picking a default direction could have side-effects elsewhere that we may not be aware of, or aware of yet. So, we should thoroughly flesh those out. Additionally, I don't think that we should just support anything, that may be ill advised, just because Neo4j does. I think that if we vear off too far, it will complicate using well defined algorithms for graphs. My thoughts. John 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. > > > > > > > > >