[DRILL-3267] Distinguish non-query statements in SQL processing and RPC protocol

• Type: Bug
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Fix Version/s: Future
• Component/s: Client - JDBC, Execution - RPC
• Assignee: Unassigned
• Reporter: Daniel Barclay
• Created: 09/Jun/15 19:20
• Updated: 01/Oct/15 16:37

Description

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

Issue Links

• is related to: DRILL-3603 Document workaround for DRILL-2560 in JDBC Javadoc doc. (etc.)
• is required by: DRILL-2560 JDBC execute calls return asynchronously for DDL statements