-
Notifications
You must be signed in to change notification settings - Fork 62
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
Query planner passes #588
Query planner passes #588
Conversation
9310e4a
to
41e6384
Compare
lang/src/org/partiql/lang/planner/transforms/AstToLogicalVisitorTransform.kt
Outdated
Show resolved
Hide resolved
- AST->logical - logical->resolved - lesolved->physical. Not yet integrated with anything--that will come in a future commit.
ac6155a
to
48a003e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just finished review for AstToLogicalVisitorTransform.kt and related test files. Generally, it looks good to me. Will continue to review rest of the changes.
lang/src/org/partiql/lang/planner/transforms/AstToLogicalVisitorTransform.kt
Show resolved
Hide resolved
lang/test/org/partiql/lang/planner/transforms/AstToLogicalVisitorTransformTests.kt
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Had a review and left some comments w/ requesting code changes if they make sense.
// Workaround for a bug in PIG that is fixed in its next release: | ||
// https://github.com/partiql/partiql-ir-generator/issues/41 | ||
fun List<IonElement>.asAnyElement() = | ||
this.map { it.asAnyElement() } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While at it, shouldn't we just release the PIG and remove this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, but partiql/partiql-ir-generator#41 hasn't been fixed yet.
import org.partiql.lang.eval.BindingCase | ||
import org.partiql.lang.eval.BindingName | ||
|
||
/** Indicates the result of an attempt to resolve a global binding. */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand we have kdoc for GlobalBindings.resolve()
but can we also add a definition for Global Binding here?
BTW.
I think it's helpful to have the link to the upcoming documentation in applicable constructs under planner
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have rephrased this to be more clear.
/** | ||
* A success case, indicates the [index] of the only possible match to the [BindingName] in a local lexical scope. | ||
* This is `internal` because [index] is an implementation detail that shouldn't be accessible outside of this | ||
* library. | ||
*/ | ||
internal data class LocalVariable(val index: Int) : ResolutionResult() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Considering that GlobalBindings.resolve()
is meant to return GlobalVariable
or undefined
, should this be here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's internal
, so it's not exposed to customers. Customer code is never intended to resolve local variables, so this fits the situation. Having this here does simplify a few things in relation in the LogicalToLogicalResolvedVisitorTransform
class. Namely, I found this to be preferable to having two variations of this sealed
class: one that is public and only has GlobalVariable
and Undefined
, and another that is private and has GlobalVariable
, Undefined
as well as LocalVariable
. There would also need to be logic to convert from the public variation to the private.
Making one member of a public
sealed class internal
is perhaps a little unusual, but unusual doesn't equate to undesirable, necessarily. Was there a specific concern you had with this approach?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wasn't worried about exposing it, I just thought this data class doesn't belong here. I think your explanation makes sense, so let's leave it as is.
data class Success<TResult>(val result: TResult, val warnings: List<Problem>) : PassResult<TResult>() | ||
|
||
/** | ||
* Indicates query planning was not successful and includes a list of errors and warnings that were encountered |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
errors and warnings
-> errors
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is designed to allow us to continue at least the current pass in the event of a semantic error instead of throwing an exception. That means its entirely possible to encounter both warnings and errors. I'll add a note.
lang/src/org/partiql/lang/planner/transforms/LogicalResolvedToPhysicalVisitorTransform.kt
Outdated
Show resolved
Hide resolved
* we keep going to provide the end user any additional error messaging, unless [ProblemHandler.handleProblem] throws | ||
* an exception when an error is logged. **If any undefined variables are detected, in order to allow traversal to | ||
* continue, a fake index value is used in place of a real one and the resolved logical plan returned by this function | ||
* is guaranteed to be invalid.** **Therefore, it is the responsibility therefore of callers to check if any problems |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A redundant _therefore`?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Out of order, actually. Fixing... EDIT: nope, redundant. Removing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
also added a couple dozen lines about $__dynamic_lookup__
/** | ||
* This is the version number of the logical and physical plans supported by this version of PartiQL. | ||
* | ||
* It would be nice to embed this in the PIG domain somehow, but this isn't supported, so we have to include it |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Didn't we introduce the version number in the new domains. I'm sure you feel the same way, but this is not great. Even if going with this hard-coding, the version doesn't tell anything about backward compatibility; shouldn't we adopt a format like SemVer
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I really think this aught to be something solved by PIG actually so I created partiql/partiql-ir-generator#121
I would like to leave this as-is for now if you don't mind.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll add a link to the ticket in the comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you also mind adding some comments to
(record plan
(stmt statement)
(version int)
)
in the partiql.ion
file, to state that the version number here will be removed and assigned to PIG domains once partiql/partiql-ir-generator#121 is resolved?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would like to leave this as-is for now if you don't mind.
I think this is something that we need to fix before we expose the API; once we have the version as is and the API is exposed, then it's too late. Happy to discuss further offline.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Offline discussion indicates this doesn't need to be addressed in this PR, but should be addressed before this hits main
. Creating an issue in the related milestone to track this: #605
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just an update on this; as a comprise, requested having the version as SemVer
hard-coded for now. @dlurton had a point on using patch
—which is for bug fixes—might not be applicable to our use-case. We ultimately agreed on having major
and minor
notions in the version for now.
return planWithAllocatedVariables to allLocals.toList() | ||
} | ||
|
||
private const val VARIABLE_ID_META_TAG = "\$variable_id" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit.: I'm thinking if we need to get all the constants in one place under planner
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general, I'd rather not have one file with a bunch of unrelated constants. Note that this is private
, putting it somewhere else means it can't be private
anymore and will pollute the package namespace. Putting the constant here also has the advantage that the definition is close to its uses, which improves readability IMHO.
lang/test/org/partiql/lang/planner/transforms/LogicalToLogicalResolvedVisitorTransformTests.kt
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just finished the review. Overall it looks good to me.
/** | ||
* This is the version number of the logical and physical plans supported by this version of PartiQL. | ||
* | ||
* It would be nice to embed this in the PIG domain somehow, but this isn't supported, so we have to include it |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you also mind adding some comments to
(record plan
(stmt statement)
(version int)
)
in the partiql.ion
file, to state that the version number here will be removed and assigned to PIG domains once partiql/partiql-ir-generator#121 is resolved?
lang/src/org/partiql/lang/planner/transforms/LogicalResolvedToPhysicalVisitorTransform.kt
Outdated
Show resolved
Hide resolved
The new commit makes sense to me and there is no more file change requested from my side. If @am357 also agrees, I think we can merge this PR. |
Merges the following PRs to `main`: - #583 - #584 - #587 - #588 - #589 - #609 - #590 - #592 Also, this adds a TODO comment (ea40e4a, requested by @am357 in offline chat) and excludes `PlannerPipeline` from the new aggregate tests which were pulled in when merging from `main` and were not part of the other PRs (34025b3). By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
Merges the following PRs to `main`: - #583 - #584 - #587 - #588 - #589 - #609 - #590 - #592 Also, this adds a TODO comment (ea40e4a, requested by @am357 in offline chat) and excludes `PlannerPipeline` from the new aggregate tests which were pulled in when merging from `main` and were not part of the other PRs (34025b3). By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
Merges the following PRs to `main`: - #583 - #584 - #587 - #588 - #589 - #609 - #590 - #592 Also, this adds a TODO comment (ea40e4a, requested by @am357 in offline chat) and excludes `PlannerPipeline` from the new aggregate tests which were pulled in when merging from `main` and were not part of the other PRs (34025b3). By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
Merges the following PRs to `main`: - #583 - #584 - #587 - #588 - #589 - #609 - #590 - #592 Also, this adds a TODO comment (ea40e4a, requested by @am357 in offline chat) and excludes `PlannerPipeline` from the new aggregate tests which were pulled in when merging from `main` and were not part of the other PRs (34025b3). By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
Originally part of #582, this commit is based on #587, which must be merged first. However, it may be helpful to review the PR introducing the
PlannerPipeline
first (#590), if more context for these changes is desired.This PR contains 3 query planner passes:
These are not yet integrated with anything--that's in #590.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.