Skip to content
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

CIP2017-04-20: Query Combinators for set operations #227

Open
wants to merge 9 commits into
base: master
Choose a base branch
from

Conversation

boggle
Copy link
Contributor

@boggle boggle commented Apr 21, 2017

This addresses #180.

View latest

Copy link
Member

@Mats-SX Mats-SX left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very nice additions!

* `CROSS`
* `THEN`

Multi-arm query combinators can only appear within a query using the syntax `<query> [<combinator> <query>]+`.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would prefer if the syntax was expressed in EBNF, similar to how other CIPs do that.

query = singleQuery | combinedQuery ;
combinedQuery = singleQuery, queryCombinator, singleQuery ;
queryCombinator = union | intersect | except | otherwise | cross | then ;
union = "UNION", ["MAX" | "ALL"] ;
...


This does not consider aliasing of subqueries; henceforth set operations over the same argument queries need to repeat the argument subqueries.

This could be addressed in a future CIP.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd suggest merging this with the previous paragraph.

This is due to its syntactic status as a query combinator.

In contrast to the other query combinators, the standard rules regarding returned record fields do not apply to `THEN`.
Instead, the set of returned record fields of both arms of `THEN` must be non-overlapping.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this required? Isn't this query perfectly reasonable:

RETURN 1 AS one, 2 AS two
THEN
RETURN one + 5 AS one, one + two AS three

And the full statement would return the fields one and three?


`OTHERWISE` is not provided by SQL and could be omitted.

SQL allows `MINUS` as an alias for `EXCEPT`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Acknowledging a potential Pythonic bias, I have a strong preference for MINUS over EXCEPT here. EXCEPT draws to mind exceptions and feels too general as a term. Conversely, MINUS leads to mathematical difference, which is entirely appropriate.

@boggle boggle changed the title CIP2017-04-20: Query Combinators CIP2017-04-20: Query Combinators for set operations Oct 16, 2017
jmarton added a commit to jmarton/slizaa-opencypher-xtext that referenced this pull request Dec 29, 2017
This also pushes `union` and `singleQuery` properties down from the RegularQuery
to the new CombinedQuery interface.
This way, SingleQuery is cleaned from those unused properties.

When 3 or more SingleQueries built up a union query, it used to be modeled
as a tree where each union node added one more SingleQuery like

```
S1
UNION
S2
UNION
S3
```

was modeled as

```
RegularQuery
 +-singleQuery: RegularQuery
 | +-singleQuery: SingleQuery S1
 | +-union:
 |   +-[list entry]: Union
 |     +-singleQuery: SingleQuery S2
 +-union:
   +-list entry: Union
     +-singleQuery: SingleQuery S3
```

From now, the representation is as follows, where RegularQuery has 2 subclasses:
 - SingleQuery used for sole queries not having any UNION clauses
 - CombinedQuery used for queries that have at least one query combinator
   (UNION in current openCypher, but other set combinators like INTERSECT
   are about to come, see opencypher/openCypher#227)

```
CombinedQuery
 +-singleQuery: SingleQuery S1
 +-union:
   +-[list entry]: Union
     +-singleQuery: SingleQuery S2
   +-[list entry]: Union
     +-singleQuery: SingleQuery S3
```
jmarton added a commit to jmarton/slizaa-opencypher-xtext that referenced this pull request Dec 30, 2017
This also pushes `union` and `singleQuery` properties down from the RegularQuery
to the new CombinedQuery interface.
This way, SingleQuery is cleaned from those unused properties.

When 3 or more SingleQueries built up a union query, it used to be modeled
as a tree where each union node added one more SingleQuery like

```
S1
UNION
S2
UNION
S3
```

was modeled as

```
RegularQuery
 +-singleQuery: RegularQuery
 | +-singleQuery: SingleQuery S1
 | +-union:
 |   +-[list entry]: Union
 |     +-singleQuery: SingleQuery S2
 +-union:
   +-list entry: Union
     +-singleQuery: SingleQuery S3
```

From now, the representation is as follows, where RegularQuery has 2 subclasses:
 - SingleQuery used for sole queries not having any UNION clauses
 - CombinedQuery used for queries that have at least one query combinator
   (UNION in current openCypher, but other set combinators like INTERSECT
   are about to come, see opencypher/openCypher#227)

```
CombinedQuery
 +-singleQuery: SingleQuery S1
 +-union:
   +-[list entry]: Union
     +-singleQuery: SingleQuery S2
   +-[list entry]: Union
     +-singleQuery: SingleQuery S3
```
@boggle
Copy link
Contributor Author

boggle commented May 7, 2018

THEN is now being defined in petraselmer/CIP-nested-subqueries.

This needs to be reflected here.

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

Successfully merging this pull request may close these issues.

None yet

5 participants