Scalar Subqueries and List Subqueries #217
Conversation
There is still some work to be done here, but comments are welcome. Ideas for examples to include in the document:
|
---- | ||
ListSubquery = '[', SingleValueSubquery, ']' ; | ||
ScalarSubquery = '<(((<', SingleValueSubquery, '>)))>' ; |
thobe
Apr 13, 2017
Author
Contributor
These fish-brackets are a place holder, we really need something better to delineate a scalar subquery. Suggestions are most welcome. It could be a keyword, I considered 'SINGLE', '(', SingleValueSubquery, ')' ;
, but single
is already used as a predicate function (actually also a type of subquery) in Cypher.
Another suggestion was 'SCALAR', '(', SingleValueSubquery, ')' ;
, but that didn't feel quite right.
These fish-brackets are a place holder, we really need something better to delineate a scalar subquery. Suggestions are most welcome. It could be a keyword, I considered 'SINGLE', '(', SingleValueSubquery, ')' ;
, but single
is already used as a predicate function (actually also a type of subquery) in Cypher.
Another suggestion was 'SCALAR', '(', SingleValueSubquery, ')' ;
, but that didn't feel quite right.
boggle
Apr 17, 2017
•
Contributor
More random ideas:
VALUE ( subquery )
(but: too generic?)
QUERY ( subquery )
(but: too generic?
EVAL ( subquery )
(but: sounds too much like metaprogramming?)
$( subquery )
(but: feels like we should reserve this syntax, perhaps for metaprogramming/templating)
(> ()-[]->(c) RETURN c <)
- Kinda like these "injection (or inception?) parens"
(| ()-[]->(c) RETURN c |)
- Bananas ftw :)
More random ideas:
VALUE ( subquery )
(but: too generic?)QUERY ( subquery )
(but: too generic?EVAL ( subquery )
(but: sounds too much like metaprogramming?)$( subquery )
(but: feels like we should reserve this syntax, perhaps for metaprogramming/templating)(> ()-[]->(c) RETURN c <)
- Kinda like these "injection (or inception?) parens"(| ()-[]->(c) RETURN c |)
- Bananas ftw :)
boggle
Apr 17, 2017
•
Contributor
Maybe the whole approach is also wrong.. for crpq we're discussing path pattern predicates.. maybe here we're missing inline function or expression-level template definitions? Given those, the quest for scalar subqueries really just becomes a search for anonymous function syntax.
DECLARE $subquery(args)=expr
...
WITH expr1 + $subquery(...)
...
Maybe the whole approach is also wrong.. for crpq we're discussing path pattern predicates.. maybe here we're missing inline function or expression-level template definitions? Given those, the quest for scalar subqueries really just becomes a search for anonymous function syntax.
DECLARE $subquery(args)=expr
...
WITH expr1 + $subquery(...)
...
boggle
Apr 18, 2017
Contributor
One more... if we don't allow subquery short forms, i.e. starting with a pattern, round parenthesis might actually suffice from a parsing point of view... (MATCH (a)-[r]->(b) RETURN r)
. It's inconsistent with the other subquery forms under discussion but it would save us the hassle of coming up with weird fancy bracket syntax.
One more... if we don't allow subquery short forms, i.e. starting with a pattern, round parenthesis might actually suffice from a parsing point of view... (MATCH (a)-[r]->(b) RETURN r)
. It's inconsistent with the other subquery forms under discussion but it would save us the hassle of coming up with weird fancy bracket syntax.
petraselmer
Apr 18, 2017
•
Contributor
-
'SCALAR'
as a keyword is simple and "does what it says on the tin"; i.e. it's very clear in its intention. What are the objections to its use?
-
$( subquery )
is rather elegant. Re boggle's comments about the drawback, would it not be reasonable to infer from context?
-
The inline function/expression-level template defs option looks very unwieldy from a readability point of view and does not marry up at all well with our other Subquery Family syntax. I don't see any advantage in it.
-
'SCALAR'
as a keyword is simple and "does what it says on the tin"; i.e. it's very clear in its intention. What are the objections to its use? -
$( subquery )
is rather elegant. Re boggle's comments about the drawback, would it not be reasonable to infer from context? -
The inline function/expression-level template defs option looks very unwieldy from a readability point of view and does not marry up at all well with our other Subquery Family syntax. I don't see any advantage in it.
thobe
Apr 18, 2017
Author
Contributor
Yes, I've had that thought as well...
if we don't allow subquery short forms /.../ round parenthesis might actually suffice from a parsing point of view
Yes, I've had that thought as well...
if we don't allow subquery short forms /.../ round parenthesis might actually suffice from a parsing point of view
thobe
Apr 18, 2017
Author
Contributor
I don't remember what the objections were to SCALAR
- perhaps we never suggested it in prior conversation? I know that we suggested VALUE
and decided that it was definitely too generic.
I'm leaning towards SCALAR
now, since I agree with Stefan that since we've used $
for parameters, we should reserve variations with that character for variations of parametrization.
I don't remember what the objections were to SCALAR
- perhaps we never suggested it in prior conversation? I know that we suggested VALUE
and decided that it was definitely too generic.
I'm leaning towards SCALAR
now, since I agree with Stefan that since we've used $
for parameters, we should reserve variations with that character for variations of parametrization.
Just realized... using round parenthesis for scalar subqueries seems not well aligned with |
This seems like a very powerful feature and I'd love to see it added. In particular I think this would give a massive boost to the GraphQL->Cypher use case seen the in Neo4j-GraphQL tools. It's been two years without much conversation, but what would it take to get this moving again? |
@a-type indeed this was first conceived of when we did a comparative analysis of Cypher and GraphQL in 2015. What is primarily needed for this to move forward is an openCypher implementor with a desire to get this into their product. In terms of actual work, the next step in terms of actual work on this proposal is to start designing TCK test cases to guide an implementation. |
And stylistic fixes for the style god.
Clarify the semantics of Scalar Subqueries. Specify the reason for having SingleValuePatternQuery, i.e. it being the future of Pattern Comprehension.
I believe that if we disallowed the I think that would be nicer. |
Does this enable sorting, filtering and using aggregate functions in Map Projections, as mentioned in this blog post? Would be awesome if neo4j could be queried like this! |
Yes, that's the goal of this proposal which I expect to also become a part of GQL. It may happen eventually in Neo4j but note this repository is about language design primarily, not implementation by vendors. |
Solves #177.
CIP2017-03-29