Voting on: CIP2018-10-29 - EXISTS and IS NOT NULL

37 views
Skip to first unread message

Tobias Lindaaker

unread,
Mar 19, 2019, 12:16:50 PM3/19/19
to openCypher
Dear openCypher community,

Neo4j would like to initiate a voting on CIP2018-10-29 (Pull Request #334). The changes proposed in this CIP were presented at the openCypher Implementers Meeting on March 7, which should have given people enough time to read and react to the CIP since then, making now a good time to gauge whether we have consensus about this proposal within the community. The voting will follow the process described in https://groups.google.com/forum/#!topic/opencypher/SCSRlplb_zc and aims to conclude at the end of this week.

The gist of this CIP is to deprecate (and remove) the use of EXISTS as a predicate function (with semantics equivalent to IS NOT NULL), and use EXISTS only for existential subqueries.

Cheers,
Tobias Lindaaker
on behalf of the Cypher language team at Neo4j

Mats Rydberg

unread,
Mar 25, 2019, 8:46:30 AM3/25/19
to openCypher
+1

I think this proposal is simplifying and replacing a rather tricky piece of functionality.

I would like the changes made to reflect that this CIP is changing the content/impact of another CIP. This may be achieved by rewriting the older CIP, or by inserting a forward-reference where the older CIP points to the newer CIP, thus not leaving readers confused if they only read the older CIP.

Mats

Duane Nickull

unread,
Mar 26, 2019, 3:43:47 AM3/26/19
to openCypher
+1 - I am for this as well. My only concerns are:

1. backward compatibility (if someone upgrades to a newer version, it would be good to have 1-2+ major versions designate the term as deprecated before sunsetting it to give devs a heads up); and

2. Confusion about potential different handling of null values (amongst vendors but also amongst developers who move from one db to another), however, the duplication between EXISTS [expression] and EXISTS [is not null] supports the removal of a redundant cypher operator.

This responsibility for #1 falls onto the vendors, the responsibility for #2 depends on developers to understand their code. 
Got my support.

D. Nickull

Tobias Lindaaker

unread,
Apr 3, 2019, 11:12:30 AM4/3/19
to openCypher
Dear openCypher community,

It has been over a week since this vote was supposed to conclude. I had hoped for some more implementers to express an opinion on this.
Quite obviously Neo4j is in support of this proposal, being the originators. It was good of Mats to demonstrate this support explicitly.
Duane, while not representing a Cypher implementation, provides very useful input, and I agree with his assessment on how backwards compatibility should be handled.

Given where we are at, I would still like to reach the recommended three positive votes from representatives of a Cypher implementation, but given the small change proposed by this CIP I will assume lazy consensus if I have not heard any objections by noon (Central European Time) on Tuesday April 9.

Cheers,
Tobias Lindaaker
on behalf of the Cypher language team at Neo4j

andrew...@neotechnology.com

unread,
Apr 3, 2019, 1:06:09 PM4/3/19
to openCypher
+1 

Simplification is good, seems like a clean proposal.


On Tuesday, March 19, 2019 at 9:16:50 AM UTC-7, Tobias Lindaaker wrote:

Tobias Lindaaker

unread,
Apr 9, 2019, 7:14:29 AM4/9/19
to openCypher
Since no objections have been raised, this proposal is now accepted by lazy consensus.

Cheers,
Tobias Lindaaker
on behalf of the Cypher language team at Neo4j
Reply all
Reply to author
Forward
0 new messages