drill-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Barclay (Drill) (JIRA)" <j...@apache.org>
Subject [jira] [Created] (DRILL-3267) Distinguish non-query statements in SQL processing and RPC protocol
Date Tue, 09 Jun 2015 19:21:01 GMT
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

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

View raw message