You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@drill.apache.org by "Daniel Barclay (Drill) (JIRA)" <ji...@apache.org> on 2015/05/12 03:05:00 UTC

[jira] [Comment Edited] (DRILL-2560) JDBC execute calls return asynchronously for DDLs

    [ https://issues.apache.org/jira/browse/DRILL-2560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14539021#comment-14539021 ] 

Daniel Barclay (Drill) edited comment on DRILL-2560 at 5/12/15 1:04 AM:
------------------------------------------------------------------------

SQL specification notes:

_Apparently_, which SQL statements return results sets and which do not is defined via <cursor specification>:

ISO-8075:2011 Part 2 Section 14.3, "<cursor specification>", says:

{quote}
Function
Define a result set.
{quote}

Therefore, again apparently, any SQL statement whose syntax includes <cursor specification> is a statement that returns a result set, and other statements are not.

(Well, <declare cursor> includes <cursor specification>, and only declaring a cursor presumably does not actually return a result by itself, so the paragraph above is only a first approximation.)

(A <cursor specification> starts with a <query expression>.  A <query expression> leads to <query specification>, <table value constructor>, or <explicit table>.  A <query specification begins with "SELECT".)


was (Author: dsbos):
SQL specification notes:

_Apparently_, which SQL statements return results sets and which do not is defined via <cursor specification>:

ISO-8075:2011 Part 2 Section 14.3, "<cursor specification>", says:

{quote}
Function
Define a result set.
{quote}

Therefore, again apparently, any SQL statement whose syntax includes <cursor specification> is a statement that returns a result set, and other statements are not.

(A <cursor specification> starts with a <query expression>.  A <query expression> leads to <query specification>, <table value constructor>, or <explicit table>.  A <query specification begins with "SELECT".)

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