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

Subclauses CIP #200

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

Subclauses CIP #200

wants to merge 6 commits into from

Conversation

Mats-SX
Copy link
Member

@Mats-SX Mats-SX commented Mar 6, 2017

This CIP is in response to #194

CIP

@Mats-SX Mats-SX added the CIP label Mar 6, 2017
Copy link

@petraselmer petraselmer left a comment

Choose a reason for hiding this comment

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

Nice one! Just a few comments


== Background

This CIP is a proposal in answer to link:https://github.com/opencypher/openCypher/issues/194[CIR-2017-194].

Choose a reason for hiding this comment

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

"answer" -> "response"

=== Semantics

The `LIMIT` subclause prevents records passing through its parent clause after the specified amount of rows, as determined by the limit expression, has been processed.
For these semantics to be well defined, the limit expression must be constant over the query lifetime, such as parameters or literals.

Choose a reason for hiding this comment

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

Can this be expanded on a bit more? It's not 100% clear what is being said. If need be, an example could be provided.

Copy link
Member Author

Choose a reason for hiding this comment

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

Expanded and gave two examples.


==== Updating queries

The use of `LIMIT` opens the possibility for certain performance optimisations.

Choose a reason for hiding this comment

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

"opens the possibility" -> "opens up the possibility"


=== Semantics

The `LIMIT` subclause prevents records passing through its parent clause after the specified amount of rows, as determined by the limit expression, has been processed.

Choose a reason for hiding this comment

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

"limit expression" -> hmmm... it reads a bit awkwardly at present. Maybe something such as "expression provided to the LIMIT clause" or something. Maybe even formatting would help, such as all in italics, or LIMIT expression?

Copy link
Member Author

Choose a reason for hiding this comment

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

How about

the expression used as argument to LIMIT

?

Choose a reason for hiding this comment

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

That works - just include "the argument"

==== Updating queries

The use of `LIMIT` opens the possibility for certain performance optimisations.
Clauses that come early in the query do not have to be evaluated over the full dataset, just enough to reach the subsequent limit.

Choose a reason for hiding this comment

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

"that come early" -> "appearing earlier"

Choose a reason for hiding this comment

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

"do not have to be evaluated over the full dataset, just enough to reach the subsequent limit."
->
"only need to be evaluated until the limit is reached, as opposed to evaluating the entire dataset."

Clauses that come early in the query do not have to be evaluated over the full dataset, just enough to reach the subsequent limit.
These optimisations are however not always applicable in combination with updating clauses.
Semantics between clauses is defined such that _all_ of a previous clause is processed (logically) before _any_ of a subsequent clause is processed.
This means that _all_ side effects must happen before a `LIMIT` is allowed to halt the processing of records in preceding clauses.

Choose a reason for hiding this comment

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

"halt" -> "terminate"

Semantics between clauses is defined such that _all_ of a previous clause is processed (logically) before _any_ of a subsequent clause is processed.
This means that _all_ side effects must happen before a `LIMIT` is allowed to halt the processing of records in preceding clauses.

Consider the below query:

Choose a reason for hiding this comment

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

"below query"
->
"following query"


Consider the below query:

.Create a producer for each item, return first 100 product ids.

Choose a reason for hiding this comment

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

Format "producer"

Choose a reason for hiding this comment

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

"item, return first 100 product ids"
->
"item, returning the first 100 product ids"

Copy link
Member Author

Choose a reason for hiding this comment

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

I don't think producer needs formatting here. The example talks about items and producers as concepts, and I think it's clear that these are then represented by nodes with matching labels.


If the user intention is to only do a partial update of the graph, the query must be rewritten:

.Create a producer for the 100 first items, return their product ids.

Choose a reason for hiding this comment

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

"100 first items, return their product ids"
->
"top 100 items, and return their product ids"

Choose a reason for hiding this comment

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

Format "producer"

- Rename file to correct name for the CIP
- Improve language
Copy link
Contributor

@thobe thobe left a comment

Choose a reason for hiding this comment

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

This should be extended to also include ORDER BY, and SKIP.

In fact all of the following sub-clauses should always go together:

  • WHERE
  • ORDER BY
  • SKIP
  • LIMIT

@Mats-SX
Copy link
Member Author

Mats-SX commented Mar 31, 2017

@thobe Extended!

@Mats-SX Mats-SX changed the title Add the LIMIT CIP Add the Subclauses CIP Mar 31, 2017
@Mats-SX Mats-SX changed the title Add the Subclauses CIP Subclauses CIP May 5, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants