New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Scalar Subqueries and List Subqueries #217

Open
wants to merge 5 commits into
base: master
from

Conversation

Projects
None yet
4 participants
@thobe
Contributor

thobe commented Apr 13, 2017

@thobe thobe added the CIP label Apr 13, 2017

@thobe

This comment has been minimized.

Contributor

thobe commented Apr 13, 2017

There is still some work to be done here, but comments are welcome.

Ideas for examples to include in the document:

  • Sorting lists
  • Filtering lists
  • Unpacking a singleton list

@thobe thobe changed the title from CIP2017-03-29 Scalar Subqueries and List Subqueries to Scalar Subqueries and List Subqueries Apr 13, 2017

----
ListSubquery = '[', SingleValueSubquery, ']' ;
ScalarSubquery = '<(((<', SingleValueSubquery, '>)))>' ;

This comment has been minimized.

@thobe

thobe Apr 13, 2017

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.

This comment has been minimized.

@boggle

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

This comment has been minimized.

@boggle

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

This comment has been minimized.

@boggle

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.

This comment has been minimized.

@petraselmer

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.

This comment has been minimized.

@thobe

thobe Apr 18, 2017

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

This comment has been minimized.

@thobe

thobe Apr 18, 2017

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.

The result of a Scalar Subquery is the single value (in the single row) produced by the subquery.
List Subqueries are read-only subqueries that produce a single value per row, and zero or more rows.
The result of a List Subquery is to collect the value of all rows produced by the subquery into a list.

This comment has been minimized.

@Mats-SX

Mats-SX Apr 18, 2017

Member

This sentence sounds a bit strange to me. Perhaps

The goal of a List Subquery

or

The result of a List Subquery is the list formed by collecting all of the values of all rows produced by the subquery.

[source, cypher]
.Collect separate lists of friends and enemies
----
MATCH (me:Person{name:$my_name})

This comment has been minimized.

@Mats-SX

Mats-SX Apr 18, 2017

Member

Cypher style: space before property predicate.
Cypher style: space after colon in property predicate.

;
SingleValuePatternSubquery = PatternPart, Filter, SingleValueReturn ;
SingleValueUnwindSubquery = 'UNWIND', Expression, ['AS', Variable, Filter] ;

This comment has been minimized.

@Mats-SX

Mats-SX Apr 18, 2017

Member

Would the UNWIND form not require a RETURN clause?

This comment has been minimized.

@thobe

thobe Apr 18, 2017

Contributor

The implication here is that the implicitly RETURN value is the value unpacked by UNWIND.

UNWIND with RETURN is handled by the regular SingleValueReadSubquery.

The use cases for this form is:

  1. Unpacking a singleton-list: SCALAR( UNWIND myList )
  2. Sorting a list: [UNWIND myList AS x ORDER BY x.age]
  3. Filtering a list: [UNWIND myList AS x WHERE x.name CONTAINS ' ']

et.c.

@boggle

This comment has been minimized.

Contributor

boggle commented May 1, 2017

Just realized... using round parenthesis for scalar subqueries seems not well aligned with EXISTS {} which also returns a single value... in a way.. Not sure how to solve this given that we overloaded exists(n.prop)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment