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