I made a Jira ticket to allow this topic to be a configuration option:
https://issues.apache.org/jira/browse/AGE2-656. I propose for the 0.8.0
release the option is to make a right directed edge, as Neo4J does.
Please give your thoughts.
On Mon, Jan 24, 2022 at 6:36 PM Josh Innis <joshin...@gmail.com> wrote:
> Personally I think long term: Alex brings up a good point with the GUC
> configuration. Let the database owner decide the behavior.
>
> On Mon, Jan 24, 2022 at 6:15 PM Josh Innis <joshin...@gmail.com> wrote:
>
> > A directed graph and undirected graph both excel at modeling different
> > problems and are used by an overlapping (though neither is a subset of
> the
> > other) set of algorithms. AGE, Neo4J and cypher are all directed models
> > that have some undirected features, which are inherently designed to be
> > ambiguous (such as MATCH with no direction given). The AGE edge datatype
> is
> > not designed to handle true undirected edges, and can only emulate them
> > using two directed edges. Which mathematically speaking and from an
> > algorithm design point of view have some subtle differences.
> >
> > On Mon, Jan 24, 2022 at 6:07 PM Jasper Blues <jas...@liberation-data.com
> >
> > wrote:
> >
> >> 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.
> >> >>>>
> >> >>>>
> >> >>>
> >> >>
> >>
> >>
>
