Re: [VOTE] Apache AGE Release 1.1.1 for PostgreSQL 12

[Jasper Blues]

+1 (again)

> On 27 Jan 2023, at 7:14 am, John Gemignani  wrote:
>
> Dear Apache Community,
>
> This is an official *RE-ISSUED* vote for the Apache AGE Release 1.1.1 for
> PostgreSQL 12.
>
> To learn more about Apache AGE, please see http://age.apache.org/
>
> Included and addressed in this release:
>
> Upgrade script from AGE for PG12 1.1.0 to 1.1.1
> Issue (#318): PGXN Support added. (#367)
> Add the ability to pass parameters to the cypher function.
> Modify the python driver's parameterization.
> Modify the go driver's parameterization.
> Fix compare_agtype_scalar_values returned result.
> Implement CI testing for Golang Driver (#372).
> Update to go version 1.19, as 1.16 is EOL (#373).
> Issue #388 - Fix python driver build from source (#389).
> Updated README.md
>
> *
>
> The git tag to be discussed and voted upon:
> https://github.com/apache/age/releases/tag/PG12/v1.1.1-rc1
>
> The git commit hash:
> commit 2f85a37f781e8f7a1112aa36e0812d9c3a50d971
>
> The release files for 1.1.1, can be found at:
> https://dist.apache.org/repos/dist/dev/age/PG12/1.1.1.rc1/
>
> Signatures used for AGE RCs can be found in this file:
> https://downloads.apache.org/age/KEYS
>
> The fingerprint of key to sign release artifacts:
> 4293 0603 8E35 AC05 4DBB  4B58 26B6 CD9D CD5B 0045
>
> For information about the contents of this release, see:
> https://github.com/apache/age/releases/tag/PG12/v1.1.1-rc1
>
> Please vote (if you are a binding vote, please state it):
>
> [ ] +1 Release this package as Apache AGE 1.1.1 for PostgreSQL 12
> [ ] 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,
>
> John Gemignani



smime.p7s
Description: S/MIME cryptographic signature

Re: [VOTE] Apache AGE 1.2.0 Release for PostgreSQL 11

[Jasper Blues]

+1

> On 27 Jan 2023, at 7:05 am, John Gemignani  wrote:
>
> Dear Apache Community,
>
> This is an official vote for the Apache AGE 1.2.0 Release for PostgreSQL 11.
>
> To learn more about Apache AGE, please see http://age.apache.org/
>
> Included and addressed in this release:
>
>Fix Python driver (#388).
>Patch to apply PR (#203) - typos and incorrect hash init.
>Update SET clause to support assigning a map (#468).
>Fix WHERE clause wrong Expr bug (#339).
>Fix multiple typos (#470).
>Updated the volatility category (from STABLE to IMMUTABLE) of multiple
> functions.
>Graph naming convention now aligns with Cypher spec. (#349).
>Fixed README typos (#436).
>Create graph instruction fixed (#414).
>Readme added for JDBC driver (#383).
>Regression tests added (#341).
>Regression tests added (#336).
>Updated Python driver Readme for clarity.
>Fixed compare_agtype_scalar to only return 1, 0, or -1.
>Created complete graph function (#342).
>Fix Travis CI warning messages.
>Updated Golang version to 1.19 (#373).
>Fixed NULL pointer on name compare (#376).
>Multiple updates to the README.md file.
>Implemented CI testing for Golang Driver (#372).
>Modify the Python driver's parameterization.
>Added license header to new files that it was missing from.
>Modify the Golang driver's usage of parameterization.
>Added the ability to pass PostgreSQL parameters to the cypher function
> (specifically for drivers).
>Use Debian Buster base image (#243).
>Updated the CONTRIBUTING.md file (#348).
>Invalid labels now return NULL instead of erroring out.
>Removed incubating from overlooked files.
>Fixed Golang driver module.
>Removed DISCLAIMER file.
>Fixed bug in delete_global_graphs.
>Fixed EXPLAIN to allow for nested cypher commands.
>Fixed bug with Call, YIELD clause ignores WHERE.
>Graph names with empty string '' are now disallowed (#251).
>Implement CALL YIELD for cypher functions.
>Update NOTICE file.
>
> *
>
> The git tag to be discussed and voted upon:
> https://github.com/apache/age/releases/tag/PG11%2Fv1.2.0-rc0
>
> The git commit hash:
> commit 67cb875d2326a257ace8f47622988fdae2332eb1
>
> The release files for 1.2.0, can be found at:
> https://dist.apache.org/repos/dist/dev/age/PG11/1.2.0.rc0/
>
> Signatures used for AGE RCs can be found in this file:
> https://downloads.apache.org/age/KEYS
>
> The fingerprint of key to sign release artifacts:
> 4293 0603 8E35 AC05 4DBB  4B58 26B6 CD9D CD5B 0045
>
> For information about the contents of this release, see:
> https://github.com/apache/age/releases/tag/PG11%2Fv1.2.0-rc0
>
> Please vote (if you are a binding vote, please state it):
>
> [ ] +1 Release this package as Apache AGE 1.2.0 for PostgreSQL 11
>
> [ ] 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,
>
> John Gemignani



smime.p7s
Description: S/MIME cryptographic signature

Re: [DISCUSS] Apache AGE 1.1.1 Release for PostgreSQL 12

[Jasper Blues]

Once again I’m in favour of release early and often, especially while the 
project is new. As long as reasonable steps are taken to prevent any issues 
that would degrade the end-user experience (which I saw did happen as a result 
of last proposal). Let’s get added value into the hands of users sooner, keep 
the feedback cycle and collaboration with community going 

> On 20 Jan 2023, at 10:52 am, John Gemignani  
> wrote:
>
> Dear Apache Community,
>
> We would like to discuss (reopen) the Apache AGE release 1.1.1 for
> PostgreSQL 12
>
> To learn more about Apache AGE, please see http://age.apache.org/
>
> Included and addressed in this release:
>
> Upgrade script from AGE for PG12 1.1.0 to 1.1.1
> Issue (#318): PGXN Support added. (#367)
> Add the ability to pass parameters to the cypher function.
> Modify the python driver's parameterization.
> Modify the go driver's parameterization.
> Fix compare_agtype_scalar_values returned result.
> Implement CI testing for Golang Driver (#372).
> Update to go version 1.19, as 1.16 is EOL (#373).
> Issue #388 - Fix python driver build from source (#389).
> Updated README.md
>
> *
>
> The git tag to be discussed and voted upon:
> https://github.com/apache/age/releases/tag/PG12/v1.1.1-rc1
>
> The git commit hash:
> commit 2f85a37f781e8f7a1112aa36e0812d9c3a50d971
>
> The release files for 1.1.1, can be found at:
> https://dist.apache.org/repos/dist/dev/age/PG12/1.1.1.rc1/
>
> Signatures used for AGE RCs can be found in this file:
> https://downloads.apache.org/age/KEYS
>
> The fingerprint of key to sign release artifacts:
> 4293 0603 8E35 AC05 4DBB  4B58 26B6 CD9D CD5B 0045
>
> For information about the contents of this release, see:
> https://github.com/apache/age/releases/tag/PG12/v1.1.1-rc1
>
> Please share your thoughts and feedback and let us know if we can call for
> a vote.
>
> Thank you,
> John Gemignani



smime.p7s
Description: S/MIME cryptographic signature

Re: [DISCUSS] Apache AGE 1.2.0 Release for PostgreSQL 11

[Jasper Blues]

I’m in favour of “release early and often”. There is enough new end-user value 
to warrant putting it out, especially while a viable set of base level features 
for wider general adoption is being put in place.  I am not personally aware of 
a reason not to release.


> On 14 Jan 2023, at 9:58 am, John Gemignani  wrote:
>
> Dear Apache Community,
>
>
> We would like to discuss the Apache AGE release 1.2.0 for PostgreSQL 11
>
>
>
> To learn more about Apache AGE, please see http://age.apache.org/
>
>
>
> Included and addressed in this release:
>
>
>Fix Python driver (#388).
>Patch to apply PR (#203) - typos and incorrect hash init.
>Update SET clause to support assigning a map (#468).
>Fix WHERE clause wrong Expr bug (#339).
>Fix multiple typos (#470).
>Updated the volatility category (from STABLE to IMMUTABLE) of multiple
> functions.
>Graph naming convention now aligns with Cypher spec. (#349).
>Fixed README typos (#436).
>Create graph instruction fixed (#414).
>Readme added for JDBC driver (#383).
>Regression tests added (#341).
>Regression tests added (#336).
>Updated Python driver Readme for clarity.
>Fixed compare_agtype_scalar to only return 1, 0, or -1.
>Created complete graph function (#342).
>Fix Travis CI warning messages.
>Updated Golang version to 1.19 (#373).
>Fixed NULL pointer on name compare (#376).
>Multiple updates to the README.md file.
>Implemented CI testing for Golang Driver (#372).
>Modify the Python driver's parameterization.
>Added license header to new files that it was missing from.
>Modify the Golang driver's usage of parameterization.
>Added the ability to pass PostgreSQL parameters to the cypher function
> (specifically for drivers).
>Use Debian Buster base image (#243).
>Updated the CONTRIBUTING.md file (#348).
>Invalid labels now return NULL instead of erroring out.
>Removed incubating from overlooked files.
>Fixed Golang driver module.
>Removed DISCLAIMER file.
>Fixed bug in delete_global_graphs.
>Fixed EXPLAIN to allow for nested cypher commands.
>Fixed bug with Call, YIELD clause ignores WHERE.
>Graph names with empty string '' are now disallowed (#251).
>Implement CALL YIELD for cypher functions.
>Update NOTICE file.
>
>
> *
>
>
>
> The git tag to be discussed and voted upon:
>
> https://github.com/apache/age/releases/tag/PG11%2Fv1.2.0-rc0
>
>
> The git commit hash:
>
>  commit 67cb875d2326a257ace8f47622988fdae2332eb1
>
>
>
> The release files for 1.2.0, can be found at:
>
> https://dist.apache.org/repos/dist/dev/age/PG11/1.2.0.rc0/
>
>
>
> Signatures used for AGE RCs can be found in this file:
>
> https://downloads.apache.org/age/KEYS
> 
>
>
>
> The fingerprint of key to sign release artifacts:
>
> 4293 0603 8E35 AC05 4DBB  4B58 26B6 CD9D CD5B 0045
>
>
>
> For information about the contents of this release, see:
>
> https://github.com/apache/age/releases/tag/PG11%2Fv1.2.0-rc0
>
>
>
> Please share your thoughts and feedback and let us know if we can call for
>
> a vote.
>
> Thank you,
> John Gemignani



smime.p7s
Description: S/MIME cryptographic signature

Re: [VOTE] Apache AGE 1.1.0 for PG12 Release

[Jasper Blues]

+1

> On 5 Nov 2022, at 10:16 am, Eya Badal Abdisho  wrote:
>
> +1 I checked the following.
>
>  - PGP Signatures.
> - SHA512 Checksums.
>  - LICENSE and NOTICE are fine.
>
> Thank you for the great release and work.
>
> Best regards,
>
>
> On Fri, Nov 4, 2022 at 11:40 AM John Gemignani 
> wrote:
>
>> Dear Apache Community,
>>
>>
>>
>> We are now opening the vote for the Apache AGE release 1.1.0 for PostgreSQL
>> 12 (PG12).
>>
>>
>>
>> To learn more about Apache AGE, please see http://age.apache.org/
>>
>>
>>
>> Functionalities included and addressed in this release:
>>
>>
>>   - Support for Agtype containment ops and GIN Indices.
>>   - Add CALL [YIELD] grammar rules for the implementation of CALL
>>   procedures.
>>   - VLE path variable integration performance patch.
>>   - Improve WHERE clause performance and support index scans.
>>   - Allow global graph contexts to see currentCommandIds.
>>   - Cache Agtype and GRAPHID OIDs.
>>   - Allow lists and maps to be used in the SET clause.
>>   - Fix bug in aggregate function collect().
>>   - Fix Bug in WHERE clause and property constraints.
>>   - Fix VLE local cache bug (crash).
>>   - Fix bug where integers were not being serialized correctly when stored
>>   in GIN indices.
>>   - Fix the VLE peek_stack_head routine to return a NULL if the stack is
>>   NULL.
>>   - Fix MERGE visibility in chained commands, SET specifically.
>>   - Fix github issue #212  - Add
>>   access operator (->, ->>) to Agtype.
>>   - Fix github issue #220  -
>> fix
>>   local cached contexts for static procedures.
>>   - Fix github issue #224  - fix
>>   regression tests to fix issues on mac with trigonometric functions.
>>   - Fix github issue #235  -
>>   when MERGE and SET were used together.
>>   - Fix github issue #240  -
>>   negative array bounds.
>>   - Fix github issue #240  -
>>   negative array bounds - addendum.
>>   - Updated README.
>>
>>
>> *
>>
>>
>>
>> The git tag to be discussed and voted upon:
>>
>> https://github.com/apache/age/releases/tag/PG12/v.1.1.0-rc0
>> 
>>
>>
>>
>> The git commit hash:
>>
>>
>> commit 1d9d60197e2cf3fc48aac573278f6f9e173ee78b
>>
>>
>> The release files for 1.1.0, can be found at:
>>
>> https://dist.apache.org/repos/dist/dev/age/PG12/1.1.0.rc0
>> 
>>
>>
>>
>> Signatures used for AGE RCs can be found in this file:
>>
>> https://downloads.apache.org/age/KEYS
>> 
>>
>>
>>
>> The fingerprint of key to sign release artifacts:
>>
>>
>> 4293 0603 8E35 AC05 4DBB  4B58 26B6 CD9D CD5B 0045
>>
>>
>>
>> For information about the contents of this release, see:
>>
>> https://github.com/apache/age/releases/tag/PG12/v1.1.0-rc0
>>
>>
>>
>> Please review that everything meets your criteria and vote accordingly.
>>
>>
>> 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.
>>
>> As always, thank you for your time.
>>
>>
>> John Gemignani
>>
>
>
> --
>
> Bitnine Global, Inc. - We create value for our clients by connecting the
> world's data.
>
>
> *Eya Badal Abdisho*
>
> Technical Engineer
>
> E-mail : eya.abdi...@bitnine.net 
>
> Mobile : +1 408-966-3301
>
> 3945 Freedom Cir., Suite 260,
> Santa Clara, CA 95054
>
> www.bitnine.net



smime.p7s
Description: S/MIME cryptographic signature

Re: [DISCUSS] Apache AGE for Postgres 12 - Version

[Jasper Blues]

I think it should be versioned after the main development/R version. 

Reasons: 

It is easy to tie back to what this version was based off, without looking up 
an index (which could be prone to error). 
If there is an as yet unfixed edge case bug affecting some portion of users on 
a particular version+pgVersion, they may have some confidence about what 
up/downgrade version to try should they also want to up/downgrade Postgres. 
Simplicity : It is one of the core XP values along with communication, 
feedback, courage and respect. 


> On Sep 30, 2022, at 5:18 AM, Eya Badal  wrote:
> 
> Dear Everyone, 
> 
> We are planning on our first release of Apache AGE for Postgres 12. It will 
> be based on the Apache AGE 1.1.0 release that supports Postgres 11. There 
> will be a prefix for this release and all Postgres 12 supported releases. 
> 
> However, since this is the first Postgres 12 release, should the version be 
> 1.0.0 or 1.1.0 because it is based on the 1.1.0 release for Postgres 11?
> 
> Please share your thoughts and suggestions. 
> 
> Thank you very much, 
> Eya 



smime.p7s
Description: S/MIME cryptographic signature

Re: [VOTE] Apache AGE 1.0.0 Release

[Jasper Blues]

+1

Releasing early and often helps the project to get traction. 

There is already a valuable feature set, that can benefit the community. 

There is a roadmap. 

It has been clearly communicated what to expect and what not to expect with 
this first cut. 

Onwards and upwards. 


> On Mar 16, 2022, at 3:03 AM, Nicholas Sorrell  wrote:
> 
> Dear Apache Community,
> 
> This is an official vote for the Apache AGE release 1.0.0 that we have been 
> working towards.
> 
> To learn more about Apache AGE, please see http://age.apache.org/
> 
> Functionality included and addressed in this release:
> 
>  - Add an upgrading SQL script file from 0.5.0 to 0.6.0
>  - Add upgrading file age--0.6.0--0.7.0.sql
>  - Refactor function get_agtype_value_object_value
>  - Age load issue (#188)
>  - Refactor agtype_access_operator
>  - Bugfix - Remove INLINE from function declaration
>  - Rebase VLE code
>  - Implement Merge Clause
>  - Bugfix: chained union logic
>  - Allow a path of one vertex
>  - Created functions for load graph from CSV files
>  - Add UNION into EXPLAIN grammar rule
>  - Implement `UNWIND` clause(#173)
>  - Bugfix:(nodejs) Corrects parsing for independence value(#177)
>  - Feat: Implement `OPTIONAL MATCH` (#175)
> 
> *
> 
> The git tag to be discussed and voted upon:
> https://github.com/apache/incubator-age/releases/tag/v1.0.0-rc0
> 
> The git commit hash:
>  commit 6660aa419f967118cfba20f554b0db1549bb15f7
> 
> The release files for 1.0.0, can be found at:
> https://dist.apache.org/repos/dist/dev/incubator/age/1.0.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:
>  C3F1 A95F 43D0 CCF6 A5EF  92C5 4E03 406A 5227 E499
> 
> For information about the contents of this release, see:
> https://github.com/apache/incubator-age/releases/tag/v1.0.0-rc0
> 
> *
> 
> Please vote:
> 
> [ ] +1 Release this package as Apache AGE 1.0.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 Regards,
> Nick Sorrell

Re: [DISCUSS] Website Overhaul

[Jasper Blues]

Sounds great. Also visible links in and out of the site should help with Google 
site ranking as well as sharing. For example, by giving bloggers, social media 
users etc links that relate directly to their talking points. 


> On Feb 10, 2022, at 10:02 PM, Nicholas Sorrell  wrote:
> 
> All,
> 
> I wanted to propose that we overhaul the website 
> (https://github.com/apache/incubator-age-website) to make it easier to 
> contribute to, easier to modify, more extensible, more accessible, and easier 
> to optimize for searching and performance.
> 
> When I created the site, there were a couple of a factors in the design 
> decisions:
> 
> Time - we were racing to get something done and presentable before a 
> conference the team was presenting at. This meant creating a site with 
> minimal "flare."
> Libraries - when we built the site way back then, we weren't sure what 3rd 
> party libraries we could incorporate. We weren't sure if Apache had rules 
> limiting the use of them, so we chose to use no libraries. This also impacted 
> the site (negatively in my opinion).
> 
> Since then, we've seen other Apache sites using 3rd party libs and we now 
> have time to redesign the site. I propose that we redesign the site using 
> Hugo. This gives us the ability to utilize Markdown, which is much more 
> accessible for contributors, and also offers more extensibility through 
> themes and plugins. I think it could also make the process of generating the 
> docs easier but I haven't fully investigated that.
> 
> Another negative about the current website is linking to content. Because of 
> the way that I've utilized anchors to show/hide content, this keeps the URL 
> slug the same no matter where you go, which makes it difficult to share, for 
> example, a "Getting Started" page with someone.
> 
> So in summary, here are the potential benefits I see:
> + easier to modify: because the content is written in markdown, it is easier 
> for people change existing pages without knowledge of HTML/CSS/JS
> + easier to contribute: again, because we will use markdown for content, it 
> is easier for people to contribute new content
> + more extensible: because Hugo has a large ecosystem, we can tap into the 
> work of others
> + more accessible:  this redesign will also have a focus on accessibility so 
> all users can engage with the content
> + better SEO:  designing with SEO in mind so that users can find out about 
> AGE is important
> + possibly easier to build docs: right now we're using a Github workflow to 
> generate these, and we could possibly wrap all of this into a single step of 
> static site generation with Hugo
> + possible blog:  another important aspect of both SEO and community 
> engagement is a blog, which can show examples and use cases of AGE's new 
> functionality with each release. The approval process for blog posts should 
> probably part of a separate conversation.
> 
> Looking forward to hearing the community's thoughts.
> 
> Thanks,
> Nick Sorrell
> 

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

[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

[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: After openCypher

[Jasper Blues]

+1 Graph Algorithms!

> On Jan 21, 2022, at 3:05 PM, Joe Fagan  wrote:
> 
> Congratulations on the great work todate.
> 
> 
> Would be nice to add
> 
> 
> Graph Algorithms eg
> 
> Traversal and Pathfinding (ShortestPath, ShortestWeightedPath, Minimum
> Weight SPanning Tree)
> 
> Centrality (PageRank)
> 
> Community Algoriths (Cluster detection, Louvain modularity
> 
> Agreement on the many graph formats to export and import from. GraphML,
> Graphviz Dot etc
> 
> 
> On Fri, 21 Jan 2022 at 06:50, Young Seung Andrew Ko <
> youngseung.and...@gmail.com> wrote:
> 
>> Thank you, AGE team!
>> 
>> It seems the project is nearing to the completion of implementing an engine
>> to process openCypher-based graph queries to an extent that it can allow
>> many important graph operations on PostgreSQL.
>> 
>> Any suggestions or recommendations on what should follow after this
>> meaningful milestone?
>> - Support for PostgreSQL 12, 13 and 14
>> - Making AGE + PostgreSQL distributed
>> - Some tools to make AGE easier to use
>> - ...
>> 
>> Andrew Ko
>> 

Re: After openCypher

[Jasper Blues]

I’m not sure if it is part of the official openCYPHER spec, however I would 
like to see support for: 

https://neo4j.com/blog/cypher-graphql-neo4j-3-1-preview/ 


Also is it possible to use AgensGraph drivers with AGE? 

The reason for asking is I would like to support GraphQL in DRIVINE.ORG 
 such that: 

Default queries and mutations can be auto-generated 

^— This will mean that using AGE with DRIVINE can serve GraphQL APIs on par 
with the leading graph DB, and AGE can be promoted as part of the GraphQL buzz. 

> On Jan 21, 2022, at 2:50 PM, Young Seung Andrew Ko 
>  wrote:
> 
> Thank you, AGE team!
> 
> It seems the project is nearing to the completion of implementing an engine
> to process openCypher-based graph queries to an extent that it can allow
> many important graph operations on PostgreSQL.
> 
> Any suggestions or recommendations on what should follow after this
> meaningful milestone?
> - Support for PostgreSQL 12, 13 and 14
> - Making AGE + PostgreSQL distributed
> - Some tools to make AGE easier to use
> - ...
> 
> Andrew Ko

Re: [VOTE] Release Apache AGE Viewer (incubating) 1.0.0-rc1

[Jasper Blues]

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

+1 Let’s show the community that progress is being made on all fronts. 

> On Jan 6, 2022, at 10:20 AM, Alex Kwak  wrote:
> 
> Dear Apache AGE Community,
> 
> This is an official vote for the Apache AGE Viewer release v1.0.0-rc1 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:
> - Graph visualization for AGE.
> - Extends edge and vertex point by point.
> 
> 
> The vote is open now and until January 8th at 6:00 PM PST and passes if a 
> majority +1 votes are cast, with a minimum of 3 +1 votes.
> 
> [ ] +1 Release this package as Apache AGE Viewer v1.0.0
> [ ] 0 I won't get in the way
> [ ] -1 Do not release this package because ...
> 
> 
> The git tag to be discussed and voted upon
> https://github.com/apache/incubator-age-viewer/releases/tag/v1.0.0-rc1
> 
> The git commit hash:
> commit 2b7fe6018d9da5ce10cf206cc6e879577a3d8051
> 
> The release files, including signatures, digests, etc. can be found at:
> https://dist.apache.org/repos/dist/dev/incubator/age/viewer/apache-age-viewer-1.0.0-incubating-rc1/
> 
> The SHA512 Checksum for these artifacts is:
> dce65e48c222d4bd0b1be8f571495b50217fcf60d82599702f3e42b36cc5afb0045b798099f981c0db13ed76a94157f9f6dadeb5940a20756bb5c2f6fb6b8009
> 
> Release artifacts are signed with the following key:
> https://downloads.apache.org/incubator/age/KEYS
> 
> The fingerprint of key to sign release artifacts:
> 0E7F 408D 8C6A 1952 329C B379 D471 FDCE 5F5C 5B82
> 
> For more information about the contents of this release, see:
> https://github.com/apache/incubator-age-viewer/releases/tag/v1.0.0-rc1
> 
> 
> 
> Best regards,
> Alex Kwak

Re: Apache AGE (Incubating) - Community Graduation Vote

[Jasper Blues]

+1 for me too! (And congrats Apache AGE team). 

Some of my consulting clients have expressed a strong interest in this project. 
One such example is a Singapore & SE Asia based company that provides digital 
transformation / business process modeling (BPM) via their proprietary software 
platform. These folks are using driving.org, my open source graph database 
library, which was built with Apache AGE in mind (also supports original 
AgensGraph and AGE Cloud).  

Apache AGE is the perfect way for them to start leveraging the power of graphs 
from a Postgres foundation.

Looking forward to seeing this project continue to grow and prosper, hopefully 
as a fully-launched Apache project. 


Jasper Blues | Liberation Data <http://liberation-data.com/>
Phone: +61 3 9028 7328
Skype: jasperblues