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
from

Conversation

Projects
None yet
4 participants
@boggle
Copy link
Contributor

commented Apr 21, 2017

This addresses #180.

View latest

@Mats-SX
Copy link
Member

left a comment

Very nice additions!

* `CROSS`
* `THEN`

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

This comment has been minimized.

Copy link
@Mats-SX

Mats-SX Apr 24, 2017

Member

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.

This comment has been minimized.

Copy link
@Mats-SX

Mats-SX Apr 24, 2017

Member

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.

This comment has been minimized.

Copy link
@Mats-SX

Mats-SX Apr 24, 2017

Member

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?

@Mats-SX

Mats-SX approved these changes May 4, 2017


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

SQL allows `MINUS` as an alias for `EXCEPT`.

This comment has been minimized.

Copy link
@technige

technige May 16, 2017

Contributor

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 force-pushed the boggle:CIP-query-combinators branch from c917667 to d361d44 Oct 16, 2017

@boggle boggle changed the title CIP2017-04-20: Query Combinators CIP2017-04-20: Query Combinators for set operations Oct 16, 2017

@boggle boggle force-pushed the boggle:CIP-query-combinators branch from d361d44 to bdf4be1 Oct 16, 2017

jmarton added a commit to jmarton/slizaa-opencypher-xtext that referenced this pull request Dec 29, 2017

Model combined UNION queries as a sequence of SingleQuery's
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

Model combined UNION queries as a sequence of SingleQuery's
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

This comment has been minimized.

Copy link
Contributor Author

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
You can’t perform that action at this time.