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