[
https://issues.apache.org/jira/browse/DRILL-2560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700613#comment-14700613
]
Daniel Barclay (Drill) commented on DRILL-2560:
-----------------------------------------------
Note that just making sure that executeQuery doesn't return until a non-query
statement has completed (e.g., having the server delay the first batch until a
non-query statement has completed) is not sufficient.
JDBC's executeQuery(...) methods are supposed to accept only query statements
(statements that return a result set), and executeUpdate(...) methods are
supposed to accept only non-query statements.
(Also, for execute(...) methods the Statement needs to return different values
depending on whether the SQL statement was a query statement or non-query
statement.)
> JDBC execute calls return asynchronously for DDLs
> -------------------------------------------------
>
> Key: DRILL-2560
> URL: https://issues.apache.org/jira/browse/DRILL-2560
> Project: Apache Drill
> Issue Type: Bug
> Components: Client - JDBC
> Affects Versions: 0.8.0
> Reporter: Chris Westin
> Assignee: Daniel Barclay (Drill)
> Fix For: 1.3.0
>
>
> While working with TestViews, I noticed that JDBC's executeQuery() returns
> immediately for drop view statements. For DDLs, users' expectation would be
> that the call would return synchronously. The same would be true for
> execute(), and executeUpdate(), if used for DDLs. This behavior is pretty
> typical for RDBMSs. This avoids the user having to consume the (non-)output
> in order to wait for the statement to complete -- otherwise it will get
> cancelled when the Statement is closed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
