drill-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Westin (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DRILL-3267) Distinguish non-query statements in SQL processing and RPC protocol
Date Wed, 01 Jul 2015 22:08:05 GMT

     [ 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)

Mime
View raw message