[
https://issues.apache.org/jira/browse/DRILL-3267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Westin updated DRILL-3267:
--------------------------------
Assignee: Daniel Barclay (Drill)
> 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
> Components: Client - JDBC, Execution - RPC
> Reporter: Daniel Barclay (Drill)
> Assignee: Daniel Barclay (Drill)
> Fix For: Future
>
>
> 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)
