-
Notifications
You must be signed in to change notification settings - Fork 81
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
SQL Calcite #3630
SQL Calcite #3630
Conversation
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.
There are many TODOs that need to either be fixed, made into SQLTODOs, or reference bugs. Also, System.out.println
s.
Many classes could use javadoc, if only to briefly describe what they are doing to deal with their calcite counterparts - I think the VC summary you gave me would probably do the job for most of these.
I'm not sure that either project specifically belongs where it is - would these make more sense in extensions or java-client?
sql/build.gradle
Outdated
useJUnitPlatform() | ||
} | ||
|
||
// todo: should this be a java 8 project? |
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.
if so, is this intended to be part of java-client, rather than a new top-level project?
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.
No; it's not meant to be part of the java-client. Ultimately, we are targetting server side SQL. That said, the conversion from String -> TableSpec is completely devoid of server side code, so it is a natural fit if the java client wants to make use out of it.
I'm going to make a better note.
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 note was more about "Why would this be java 8, if it isnt meant to be designed for clients that can't update"
@Override | ||
public Table of(TicketTable ticketTable) { | ||
final String scanTicket = new String(ticketTable.ticket(), StandardCharsets.UTF_8); | ||
if (!scanTicket.startsWith("scan/")) { |
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.
here an TableScanAdapter should find a way to have this be a constant - for my money, i'm not sure this class belongs in engine itself.
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've updated the interface to give clear ownership to the calling side; the SqlAdapter layer won't be creating any TicketTables that the caller needs to know the format of.
qst/src/main/java/io/deephaven/qst/table/TableLabelVisitor.java
Outdated
Show resolved
Hide resolved
qst/src/main/java/io/deephaven/qst/table/TableLabelVisitor.java
Outdated
Show resolved
Hide resolved
import java.nio.file.Path; | ||
import java.util.List; | ||
|
||
import static org.assertj.core.api.Assertions.assertThat; |
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.
Moving from numbers to descriptive names would make this better and more maintainable.
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.
or maybe named constants in the test class
…s case-sensitivity
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.
Finished re-review of files I looked at on Tuesday
qst/src/main/java/io/deephaven/qst/table/TableLabelVisitor.java
Outdated
Show resolved
Hide resolved
Integrations/src/main/java/io/deephaven/integrations/python/PythonDeephavenSession.java
Outdated
Show resolved
Hide resolved
sql/src/main/java/io/deephaven/sql/RexNodeExpressionAdapterImpl.java
Outdated
Show resolved
Hide resolved
I think it's very important that we write a comprehensive, user-facing document explaining what we support, what we want to, what we never will, etc. |
|
||
@Override | ||
public void visit(FloatType floatType) { | ||
out = create(SqlTypeName.FLOAT); |
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.
Is this correct?
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.
Good call. Should be REAL.
result_table = sql.eval("SELECT CURRENT_TIMESTAMP") | ||
self.assertEqual(result_table.size, 1) | ||
|
||
|
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.
We tested a few other scoping scenarios for the table methods. Consider testing some of those here as well. See for example the stuff around this line in the test file.
https://github.com/deephaven/deephaven-core/blob/main/py/server/tests/test_table.py#L730
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.
The scoping for SQL is a bit more limited, as it's limited to only referencing table names. Custom functions are on the roadmap, and we'd be able to get more tests of this kind then.
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.
The test cases I'm referring to as examples make sure that query scope is properly obtained from the correct Python scope.
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've added a new test, but it's not really testing anything new - is there another specific SQL test you want to see?
j_py_script_session.popScope() | ||
|
||
|
||
def eval( |
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.
eval
is a built-in python function, so we are better off renaming this to sql_eval
or something else.
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.
The naming was intentional, as I think the built-in eval
is very similar in spirit to evaluating SQL (thus, also why I exposed globals/locals as params). I'm hoping we always reference it qualified by the sql module:
from deephaven.experimental import sql
sql.eval(...)
Or, I could get behind the more explicit name evaluate(...)
if we prefer it to be "unique".
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.
The user can always do that themselves:
from deephaven.experimental.sql import eval as sql_eval
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.
Overwriting a built-in function is generally considered to be bad practice.
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've changed the function name to "evaluate"
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'm content to merge this, once the Python crowd is on board.
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.
LGTM
Labels indicate documentation is required. Issues for documentation have been opened: How-to: https://github.com/deephaven/deephaven.io/issues/2707 |
This is a large, self-contained PR that adds server-side SQL parsing and execution support.
The SQL implementation logic is largely self-contained in the
sql
package, and the public interface it exposes is very small. Its job is to translate SQL strings into TableSpec, but not to execute it. This keeps dependencies at a minimum, and allows for the usage ofsql
by java clients if they so desire.The server-side SQL execution is the responsibility of the
engine-sql
package. The package is also wrapped in thedeephaven.experimental.sql
python module:This should be considered an experimental / minimial-viable-SQL offering - there is a lot of opportunity for improvements and optimizations in the future. Some of these have been captured with "SQLTODO"s with descriptions inline, as well as listed in
sql/DEVELOPMENT.md
.