Daniel Barclay (Drill) created DRILL-3267:
---------------------------------------------
Summary: Distinguish non-query statements in SQL processing and
RPC protocol
Key: DRILL-3267
URL: https://issues.apache.org/jira/browse/DRILL-3267
Project: Apache Drill
Issue Type: Bug
Reporter: Daniel Barclay (Drill)
Drill needs to distinguish, in some way that the client side can detect,
between SQL statements whose purpose is to change state (e.g., DROP VIEW and
SET SCHEMA statements) and statements whose purpose is to return a result set
(e.g., SELECT statements).
This distinction is needed to support normal behavior of JDBC's execute
methods: When called to execute a DDL-like statement, an execute method will
not return until the action is completed. (See DRILL-2560.)
(For query statements, an execute method has to return before the query is
fully complete (the result set has been read), because of course it has to
return the ResultSet through which the results are read.)
Currently, Drill returns a result set for any SQL statement: the real result
set for a query statement, and a dummy/status result set (typically with
columns "ok" and "summary") for a DDL-like statement.
This means that the JDBC layer cannot distinguish between statements for which
execute methods should wait for completion before returning vs. statements for
which execute methods can return to client code. (Again, see DRILL-2560.)
One solution might be to not return any dummy/status result set for DDL-like
statements. If that meant that no QueryData messages were sent for such a
statement, then the first message after the query-ID message would be the
termination message.
In that case, the JDBC layer could wait for the first post-query-ID message
before returning from an execute method:
If the message is a termination message, then the statement was a DDL-like
statement, the JDBC should have waited for completion, it _has_ already waited,
and can return (returning no result set).
If the message is a QueryData message, then the statement was a query
statement, so the method doesn't need to wait any further (and has waited
enough to allow parsing or other up-front errors to be reported from the
execute method rather than later from ResultSet.next()), and can return
(returning a result set).
Another solution might be to have multiple forms (combinations of values) of
the QueryData message.
Another thing to keep in mind is JDBC's support for statements that return
multiple results, where each result can be either a result set or an integer
(e.g., an inserted-records count). If Drill ever needs to support that, then
QueryData or other messages will need something.)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
