Re: [VOTE] Apache AGE 0.7.0 Release

[Josh Innis]

I feel that we should ask this question: are we judging copyright claims at
high level or low levels of programming. Or rather: compiled or
non-compiled code. Take: src/include/parser/cypher_expr.h, this is a file
in incubator-Apache AGE. The name of the function call declared in that
function: transform_cypher_expr is unique. The idea: pass a parsestate
object, a pointer value representing an object that is the expression that
represents the node and an enum representing where the expression came from
as a function that will pass back a transformation phase object that
represents the same thing: is not.

The binary code that will be executed in run-time is a combination of
Postgres and unique executable code that Postgres consciously allows and
designed into their system via static variables. Is the binary code
copyright protected and an issue? Even though it is not bundled with the
code and will not coexist with the code until compile time? Please let us
know.


We have tried to isolate Postgres code from Apace AGE code, but we need
mentorship on whether that means compiled or non-compiled code. There are
no further plans to do so, because we believe there is no reason to do so.
Please help us if we are wrong.


On Mon, Jan 24, 2022 at 9:27 PM Juan Pan  wrote:

> Thanks, then +1 based on my checking
>
>
>
>
> --
> Juan Pan(Trista), Twitter: @tristaZero
>
>
> On 01/24/2022 02:03，Josh Innis wrote：
> There is some code that the AGE team wrote that is in those files, but no
> third party code is in those files.
>
> On Sun, Jan 23, 2022 at 8:46 AM John Gemignani 
> wrote:
>
> Hi Juan,
>
> Not necessarily the file names but the contents of those files.
>
>
> John
>
> On Sun, Jan 23, 2022, 3:31 AM Juan Pan  wrote:
>
> Hi Josh,
>
>
> I see. I just want to double check the following files all comes from
> PostgreSQL, not from others, right?
>
>
>
>
>
>
>
>
> --
> Juan Pan(Trista), Twitter: @tristaZero
>
>
> On 01/23/2022 11:43，Josh Innis wrote：
> Hi Trista,
>
> From the discussion from the last release the team reviewed the project
> and
> determined that there was a large enough amount of the Postgres code base
> in those files to warrant  the Postgres header instead of the Apache
> header.
>
> On Sat, Jan 22, 2022 at 6:35 AM Juan Pan  wrote:
>
> Hello,
>
>
>
> [x] Download links are valid.
>
> [x] Checksums and PGP signatures are valid.
>
> [x] LICENSE, NOTICE and DISCLAIMER files exist.
>
> [ ] All files have license headers if necessary.
>
>
>
>
> The following files with source coding are all from Postgres project?
> 
> apache-age-0.7.0-incubating/.gitignore
> apache-age-0.7.0-incubating/.travis.yml
> apache-age-0.7.0-incubating/CONTRIBUTING.md
> apache-age-0.7.0-incubating/README.md
> apache-age-0.7.0-incubating/doc/.gitignore
> apache-age-0.7.0-incubating/drivers/golang/README.md
> apache-age-0.7.0-incubating/drivers/golang/TYPES.md
> apache-age-0.7.0-incubating/drivers/golang/parser/README.md
> apache-age-0.7.0-incubating/drivers/nodejs/README.md
> apache-age-0.7.0-incubating/drivers/python/README.md
> apache-age-0.7.0-incubating/drivers/python/antlr/README.md
>
>
> apache-age-0.7.0-incubating/drivers/python/samples/apache-age-agtypes.ipynb
> apache-age-0.7.0-incubating/drivers/python/samples/apache-age-basic.ipynb
> apache-age-0.7.0-incubating/drivers/python/samples/apache-age-note.ipynb
> apache-age-0.7.0-incubating/regress/.gitignore
> apache-age-0.7.0-incubating/src/backend/executor/cypher_utils.c
> apache-age-0.7.0-incubating/src/backend/parser/.gitignore
> apache-age-0.7.0-incubating/src/backend/parser/cypher_clause.c
> apache-age-0.7.0-incubating/src/backend/parser/cypher_expr.c
> apache-age-0.7.0-incubating/src/backend/parser/cypher_item.c
> apache-age-0.7.0-incubating/src/backend/parser/cypher_keywords.c
> apache-age-0.7.0-incubating/src/backend/parser/cypher_parse_agg.c
> apache-age-0.7.0-incubating/src/backend/parser/cypher_parse_node.c
> apache-age-0.7.0-incubating/src/backend/utils/ag_func.c
> apache-age-0.7.0-incubating/src/backend/utils/adt/ag_float8_supp.c
> apache-age-0.7.0-incubating/src/backend/utils/adt/agtype.c
> apache-age-0.7.0-incubating/src/backend/utils/adt/agtype_parser.c
> apache-age-0.7.0-incubating/src/backend/utils/adt/agtype_util.c
> apache-age-0.7.0-incubating/src/include/parser/.gitignore
> apache-age-0.7.0-incubating/src/include/parser/ag_scanner.h
> apache-age-0.7.0-incubating/src/include/parser/cypher_expr.h
> apache-age-0.7.0-incubating/src/include/parser/cypher_parse_agg.h
> apache-age-0.7.0-incubating/src/include/utils/ag_float8_supp.h
> apache-age-0.7.0-incubating/src/include/utils/ag_func.h
> apache-age-0.7.0-incubating/src/include/utils/agtype.h
> apache-age-0.7.0-incubating/src/include/utils/agtype_parser.h
>
>
>
>
>
>
>
> --
> Juan 

Re: [DISCUSS and VOTE] AGEViewer dockerhub presence

[Joe Fagan]

Hi all, please vote to utilise dockerhub as a distribution method for
Viewer as it is for AGE

@Felix

The direction from Infra team on the incubator AGE dockerhub request was...
"Neither of these threads expressly confirm the project's desire to adopt
DockerHub distribution, they are just discussions about issues related to
it. Please have your project mentors evaluate and approve the requested
distribution method."

Can I ask you to either vote, or evaluate and approve the
dockerhub distribution method for Viewer too, whichever is most
appropriate, or give further specific advice.

Thanks
Joe

On Tue, 25 Jan 2022 at 05:59, Felix Cheung 
wrote:

> I guess I’m linking to myself. I see infra asks for mentor, but as a
> community you should just have a vote. You can explicitly ask a mentor to
> vote too
>
> https://lists.apache.org/thread/oxzo04gxxkqvmtw7rmzkw8t2d8cf3nwo
> 
> From: Felix Cheung 
> Sent: Monday, January 24, 2022 9:51:05 PM
> To: dev@age.apache.org 
> Subject: Re: [DISCUSS] AGEViewer dockerhub presence
>
> Shouldn’t this be a vote?
>
> Please see
> https://issues.apache.org/jira/plugins/servlet/mobile#issue/INFRA-22356
> 
> From: Joe Fagan 
> Sent: Monday, January 24, 2022 7:34:36 AM
> To: dev@age.apache.org 
> Subject: [DISCUSS] AGEViewer dockerhub presence
>
> Dear mentors,
>
> We would like to have an image for Incubator AGE Viewer at hub.docker.com.
> Is it possible to approve the creation of
> https://hub.docker.com/r/apache/age-viewer
> 
>
> We will not require push access to this and can instead use automated build
> based on tags in the https://github.com/apache/incubator-age-viewer
> repository.
>
> Once we have your approval we will raise a ticket on JIRA to the Infra Team
> with the relevant details.
>
> Thank you
> Joe
>

Re: [DISCUSS] AGEViewer dockerhub presence

[Felix Cheung]

I guess I’m linking to myself. I see infra asks for mentor, but as a community 
you should just have a vote. You can explicitly ask a mentor to vote too

https://lists.apache.org/thread/oxzo04gxxkqvmtw7rmzkw8t2d8cf3nwo

From: Felix Cheung 
Sent: Monday, January 24, 2022 9:51:05 PM
To: dev@age.apache.org 
Subject: Re: [DISCUSS] AGEViewer dockerhub presence

Shouldn’t this be a vote?

Please see 
https://issues.apache.org/jira/plugins/servlet/mobile#issue/INFRA-22356

From: Joe Fagan 
Sent: Monday, January 24, 2022 7:34:36 AM
To: dev@age.apache.org 
Subject: [DISCUSS] AGEViewer dockerhub presence

Dear mentors,

We would like to have an image for Incubator AGE Viewer at hub.docker.com.
Is it possible to approve the creation of
https://hub.docker.com/r/apache/age-viewer


We will not require push access to this and can instead use automated build
based on tags in the https://github.com/apache/incubator-age-viewer
repository.

Once we have your approval we will raise a ticket on JIRA to the Infra Team
with the relevant details.

Thank you
Joe

Re: [DISCUSS] AGEViewer dockerhub presence

[Felix Cheung]

Shouldn’t this be a vote?

Please see 
https://issues.apache.org/jira/plugins/servlet/mobile#issue/INFRA-22356

From: Joe Fagan 
Sent: Monday, January 24, 2022 7:34:36 AM
To: dev@age.apache.org 
Subject: [DISCUSS] AGEViewer dockerhub presence

Dear mentors,

We would like to have an image for Incubator AGE Viewer at hub.docker.com.
Is it possible to approve the creation of
https://hub.docker.com/r/apache/age-viewer


We will not require push access to this and can instead use automated build
based on tags in the https://github.com/apache/incubator-age-viewer
repository.

Once we have your approval we will raise a ticket on JIRA to the Infra Team
with the relevant details.

Thank you
Joe

Re: [VOTE] Apache AGE 0.7.0 Release

[Juan Pan]

Thanks, then +1 based on my checking



--
Juan Pan(Trista), Twitter: @tristaZero


On 01/24/2022 02:03，Josh Innis wrote：
There is some code that the AGE team wrote that is in those files, but no
third party code is in those files.

On Sun, Jan 23, 2022 at 8:46 AM John Gemignani 
wrote:

Hi Juan,

Not necessarily the file names but the contents of those files.


John

On Sun, Jan 23, 2022, 3:31 AM Juan Pan  wrote:

Hi Josh,


I see. I just want to double check the following files all comes from
PostgreSQL, not from others, right?







--
Juan Pan(Trista), Twitter: @tristaZero


On 01/23/2022 11:43，Josh Innis wrote：
Hi Trista,

From the discussion from the last release the team reviewed the project
and
determined that there was a large enough amount of the Postgres code base
in those files to warrant  the Postgres header instead of the Apache
header.

On Sat, Jan 22, 2022 at 6:35 AM Juan Pan  wrote:

Hello,



[x] Download links are valid.

[x] Checksums and PGP signatures are valid.

[x] LICENSE, NOTICE and DISCLAIMER files exist.

[ ] All files have license headers if necessary.




The following files with source coding are all from Postgres project?

apache-age-0.7.0-incubating/.gitignore
apache-age-0.7.0-incubating/.travis.yml
apache-age-0.7.0-incubating/CONTRIBUTING.md
apache-age-0.7.0-incubating/README.md
apache-age-0.7.0-incubating/doc/.gitignore
apache-age-0.7.0-incubating/drivers/golang/README.md
apache-age-0.7.0-incubating/drivers/golang/TYPES.md
apache-age-0.7.0-incubating/drivers/golang/parser/README.md
apache-age-0.7.0-incubating/drivers/nodejs/README.md
apache-age-0.7.0-incubating/drivers/python/README.md
apache-age-0.7.0-incubating/drivers/python/antlr/README.md


apache-age-0.7.0-incubating/drivers/python/samples/apache-age-agtypes.ipynb
apache-age-0.7.0-incubating/drivers/python/samples/apache-age-basic.ipynb
apache-age-0.7.0-incubating/drivers/python/samples/apache-age-note.ipynb
apache-age-0.7.0-incubating/regress/.gitignore
apache-age-0.7.0-incubating/src/backend/executor/cypher_utils.c
apache-age-0.7.0-incubating/src/backend/parser/.gitignore
apache-age-0.7.0-incubating/src/backend/parser/cypher_clause.c
apache-age-0.7.0-incubating/src/backend/parser/cypher_expr.c
apache-age-0.7.0-incubating/src/backend/parser/cypher_item.c
apache-age-0.7.0-incubating/src/backend/parser/cypher_keywords.c
apache-age-0.7.0-incubating/src/backend/parser/cypher_parse_agg.c
apache-age-0.7.0-incubating/src/backend/parser/cypher_parse_node.c
apache-age-0.7.0-incubating/src/backend/utils/ag_func.c
apache-age-0.7.0-incubating/src/backend/utils/adt/ag_float8_supp.c
apache-age-0.7.0-incubating/src/backend/utils/adt/agtype.c
apache-age-0.7.0-incubating/src/backend/utils/adt/agtype_parser.c
apache-age-0.7.0-incubating/src/backend/utils/adt/agtype_util.c
apache-age-0.7.0-incubating/src/include/parser/.gitignore
apache-age-0.7.0-incubating/src/include/parser/ag_scanner.h
apache-age-0.7.0-incubating/src/include/parser/cypher_expr.h
apache-age-0.7.0-incubating/src/include/parser/cypher_parse_agg.h
apache-age-0.7.0-incubating/src/include/utils/ag_float8_supp.h
apache-age-0.7.0-incubating/src/include/utils/ag_func.h
apache-age-0.7.0-incubating/src/include/utils/agtype.h
apache-age-0.7.0-incubating/src/include/utils/agtype_parser.h






--
Juan Pan(Trista), Twitter: @tristaZero


On 01/19/2022 07:37，Dehowe Feng wrote：
Dear Apache Community,

This is an official vote for the Apache AGE release 0.7.0. that we have
been
working toward it.

To learn more about Apache AGE, please see http://age.apache.org/

Functionalities included and addressed in this release:

*Add VLE core to the MATCH clause.
*Added support for various list functions
*range()
*relationships()
*keys()
*label()
*nodes()
*reverse()
*Various bug fixes

*

The git tag to be discussed and voted upon:
https://github.com/apache/incubator-age/releases/tag/v.0.7.0-rc0

The git commit hash: commit d0175f4a2fb03f28c356ea43da3bd48a47f5ef42

The release files for 0.7.0, can be found at:
https://dist.apache.org/repos/dist/dev/incubator/age/0.7.0.rc0/

Signatures used for AGE RCs can be found in this file:
https://downloads.apache.org/incubator/age/KEYS

The fingerprint of key to sign release artifacts:
847F A9F0 CB17 2A51 DEC9 D0F3 8285 D595 875F 13B1

For information about the contents of this release, see:
https://github.com/apache/incubator-age/releases/tag/v.0.7.0-rc0



Please vote:


[ ] +1 Release this package as Apache AGE 0.7.0
[ ] 0 I won't get in the way
[ ] -1 Do not release this package because ...


This vote will be open for 72 hours.

Thank you for your time.


Best,
Dehowe Feng

Re: [DISCUSS] Ambiguity in the MERGE Specification

[Josh Innis]

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

Re: [DISCUSS] Ambiguity in the MERGE Specification

[Josh Innis]

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

Re: [DISCUSS] Ambiguity in the MERGE Specification

[Jasper Blues]

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

Re: [DISCUSS] Ambiguity in the MERGE Specification

[Josh Innis]

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

Re: [DISCUSS] Ambiguity in the MERGE Specification

[John Gemignani]

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

Re: [DISCUSS] Ambiguity in the MERGE Specification

[Josh Innis]

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

Re: [DISCUSS] Ambiguity in the MERGE Specification

[John Gemignani]

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

Re: [DISCUSS] Ambiguity in the MERGE Specification

[Jasper Blues]

Or to be fair: The spec itself _is_ ambiguous, however we should also consider 
and adhere defacto standards, I think, unless there’s a very strong reason not 
to. 

> On Jan 25, 2022, at 9:12 AM, Nicholas Sorrell  wrote:
> 
> I agree with Jasper's response. My preferences would also be the same order:  
> Try to keep it arbitrary/random, else pick a direction. Option 1 of rejecting 
> the statement deviates from the spec and creates interoperability issues.
> 
> 
> From: Jasper Blues 
> Sent: Monday, January 24, 2022 6:35 PM
> To: dev@age.apache.org 
> Subject: Re: [DISCUSS] Ambiguity in the MERGE Specification
> 
> 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  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.
> 

Re: [DISCUSS] Ambiguity in the MERGE Specification

[Nicholas Sorrell]

I agree with Jasper's response. My preferences would also be the same order:  
Try to keep it arbitrary/random, else pick a direction. Option 1 of rejecting 
the statement deviates from the spec and creates interoperability issues.


From: Jasper Blues 
Sent: Monday, January 24, 2022 6:35 PM
To: dev@age.apache.org 
Subject: Re: [DISCUSS] Ambiguity in the MERGE Specification

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

Re: [DISCUSS] Ambiguity in the MERGE Specification

[Jasper Blues]

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

Re: [DISCUSS] Ambiguity in the MERGE Specification

[Alex Kwak]

Option1 +1

In terms of OpenCypher's grammar compatibility, Option2 seems to be a very good 
choice. However, in the case of a joint project, not a solo project, this 
choice may cause confusion.

So, in a different opinion, how about introducing GUC, Option1 as the default 
and choose between Option1 and Option2.

Alex

On 2022/01/24 23:06:13 Josh Innis 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.
> 

[DISCUSS] Ambiguity in the MERGE Specification

[Josh Innis]

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.

Re: [VOTE] Apache AGE 0.7.0 Release

[John Gemignani]

vongosling -

"Do we have a plan to transfer all pg files to an external directory?"

Could you please clarify what *you *mean by an external directory? Is it
another directory in our repository or not in our repository at all?

Additionally, is this a requirement? Per Justin, or at least from my
understanding of what Justin stated and please correct me if I am wrong, it
is desirable to keep the code in another directory in the repository but,
it is not necessary.

What we have been working on is slowly migrating code out of these files
and trying to segregate our new code. However, this is a slow process as
there are a lot of interdependencies. Additionally, as the core code for
AGE is heavily based off of JSONB, some of our code cannot be fully
separated or segregated.

So, to answer your question, yes, we have been working on a plan to
separate and segregate our code. But, to an external directory, that
depends on what you mean. There will always be files with a mix of our code
and PG code due to the nature of this extension - which has been stated
before.

John

On Sun, Jan 23, 2022 at 7:14 PM vongosling  wrote:

> Do we have a plan to transfer all pg files to an external directory? I have
> seen we have many files like we have pointed.
>
> Josh Innis  于2022年1月24日周一 02:03写道：
>
> > There is some code that the AGE team wrote that is in those files, but no
> > third party code is in those files.
> >
> > On Sun, Jan 23, 2022 at 8:46 AM John Gemignani 
> > wrote:
> >
> > > Hi Juan,
> > >
> > > Not necessarily the file names but the contents of those files.
> > >
> > >
> > > John
> > >
> > > On Sun, Jan 23, 2022, 3:31 AM Juan Pan  wrote:
> > >
> > > > Hi Josh,
> > > >
> > > >
> > > > I see. I just want to double check the following files all comes from
> > > > PostgreSQL, not from others, right?
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> >
> --
> > > > Juan Pan(Trista), Twitter: @tristaZero
> > > >
> > > >
> > > > On 01/23/2022 11:43，Josh Innis wrote：
> > > > Hi Trista,
> > > >
> > > > From the discussion from the last release the team reviewed the
> project
> > > and
> > > > determined that there was a large enough amount of the Postgres code
> > base
> > > > in those files to warrant  the Postgres header instead of the Apache
> > > > header.
> > > >
> > > > On Sat, Jan 22, 2022 at 6:35 AM Juan Pan  wrote:
> > > >
> > > > Hello,
> > > >
> > > >
> > > >
> > > > [x] Download links are valid.
> > > >
> > > > [x] Checksums and PGP signatures are valid.
> > > >
> > > > [x] LICENSE, NOTICE and DISCLAIMER files exist.
> > > >
> > > > [ ] All files have license headers if necessary.
> > > >
> > > >
> > > >
> > > >
> > > > The following files with source coding are all from Postgres project?
> > > > 
> > > > apache-age-0.7.0-incubating/.gitignore
> > > > apache-age-0.7.0-incubating/.travis.yml
> > > > apache-age-0.7.0-incubating/CONTRIBUTING.md
> > > > apache-age-0.7.0-incubating/README.md
> > > > apache-age-0.7.0-incubating/doc/.gitignore
> > > > apache-age-0.7.0-incubating/drivers/golang/README.md
> > > > apache-age-0.7.0-incubating/drivers/golang/TYPES.md
> > > > apache-age-0.7.0-incubating/drivers/golang/parser/README.md
> > > > apache-age-0.7.0-incubating/drivers/nodejs/README.md
> > > > apache-age-0.7.0-incubating/drivers/python/README.md
> > > > apache-age-0.7.0-incubating/drivers/python/antlr/README.md
> > > >
> > > >
> > >
> >
> apache-age-0.7.0-incubating/drivers/python/samples/apache-age-agtypes.ipynb
> > > >
> > apache-age-0.7.0-incubating/drivers/python/samples/apache-age-basic.ipynb
> > > >
> > apache-age-0.7.0-incubating/drivers/python/samples/apache-age-note.ipynb
> > > > apache-age-0.7.0-incubating/regress/.gitignore
> > > > apache-age-0.7.0-incubating/src/backend/executor/cypher_utils.c
> > > > apache-age-0.7.0-incubating/src/backend/parser/.gitignore
> > > > apache-age-0.7.0-incubating/src/backend/parser/cypher_clause.c
> > > > apache-age-0.7.0-incubating/src/backend/parser/cypher_expr.c
> > > > apache-age-0.7.0-incubating/src/backend/parser/cypher_item.c
> > > > apache-age-0.7.0-incubating/src/backend/parser/cypher_keywords.c
> > > > apache-age-0.7.0-incubating/src/backend/parser/cypher_parse_agg.c
> > > > apache-age-0.7.0-incubating/src/backend/parser/cypher_parse_node.c
> > > > apache-age-0.7.0-incubating/src/backend/utils/ag_func.c
> > > > apache-age-0.7.0-incubating/src/backend/utils/adt/ag_float8_supp.c
> > > > apache-age-0.7.0-incubating/src/backend/utils/adt/agtype.c
> > > > apache-age-0.7.0-incubating/src/backend/utils/adt/agtype_parser.c
> > > > apache-age-0.7.0-incubating/src/backend/utils/adt/agtype_util.c
> > > > apache-age-0.7.0-incubating/src/include/parser/.gitignore
> > > > apache-age-0.7.0-incubating/src/include/parser/ag_scanner.h
> > > > apache-age-0.7.0-incubating/src/include/parser/cypher_expr.h
> > > > apache-age-0.7.0-incubating/src/include/parser/cypher_parse_agg.h
> > > > 

[DISCUSS] AGEViewer dockerhub presence

[Joe Fagan]

Dear mentors,

We would like to have an image for Incubator AGE Viewer at hub.docker.com.
Is it possible to approve the creation of
https://hub.docker.com/r/apache/age-viewer


We will not require push access to this and can instead use automated build
based on tags in the https://github.com/apache/incubator-age-viewer
repository.

Once we have your approval we will raise a ticket on JIRA to the Infra Team
with the relevant details.

Thank you
Joe

Re: Apache AGE (Incubating) SGA/IP Clearance

[Eya Badal]

Hello Craig, 

Thank you very much. We discussed this with our mentor and we were able to fix 
the issues. 

Best regards, 
Eya

On 2022/01/20 06:08:19 Craig Russell wrote:
> Hi Eya,
> 
> Please discuss the status of the project with your mentors. The Secretary's 
> role is limited to recording documents.
> 
> Warm regards,
> Craig
> 
> > On Jan 19, 2022, at 4:36 PM, Eya Badal  wrote:
> > 
> > Hello Secretary, 
> > 
> > Hope you are well. When I check the Whimsy for AGE I see the RED issues:
> > No Software Grant and No IP Clearance Filed
> > No Release Yet/Missing ASF Copyright Headers on Source Code
> > No Release Yet/Binary has licensing issues
> > 
> > We submitted the Software Grant back in July 2020 and also here is the 
> > ticket for IP Clearance(https://issues.apache.org/jira/browse/AGEOLD-1 
> > ) that was opened in July 
> > 2020 as well. 
> > 
> > As of releases, we have 4 official Apache releases and no license issues.  
> > ASF Copyright Headers also exist on source code: 
> > https://github.com/apache/incubator-age 
> > 
> > 
> > For convenience, I attached the SGA ad CLA that we submitted back in July 
> > 2020 as well. 
> > 
> > Could you please advise? 
> > 
> > Best Regards, 
> > Eya
> > 
> > 
> 
> Craig L Russell
> c...@apache.org
> 
>