[
https://issues.apache.org/jira/browse/CALCITE-5443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5443:
------------------------------------
Labels: pull-request-available (was: )
> After Statement.getMoreResults() has returned false,
> Statement.getUpdateCount() should return -1
> ------------------------------------------------------------------------------------------------
>
> Key: CALCITE-5443
> URL: https://issues.apache.org/jira/browse/CALCITE-5443
> Project: Calcite
> Issue Type: Bug
> Components: avatica
> Reporter: Gregory Hart
> Assignee: Gregory Hart
> Priority: Major
> Labels: pull-request-available
> Fix For: avatica-1.23.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> After {{java.sql.Statement.getMoreResults()}} has returned false, the JDBC
> spec says that {{Statement.getUpdateCount()}} should return {{-1}}. This
> value indicates to the client that there are no additional result sets
> available. (Calcite currently supports at most one result set per SQL
> statement, and so there are never additional result sets available.)
> Therefore the correct behavior for Avatica would be for the implementation of
> {{getMoreResults}} to reset {{updateCount}}.
> *Background*
> Some databases, such as Oracle Database, allow stored procedures to return
> multiple result sets. The JDBC API provides {{Statement.getMoreResults()}}
> for users to check if the statement has more than one result set and to
> retrieve the next result set. Calcite does not support this feature and only
> returns zero or one result set. The problem is that Calcite sometimes returns
> the wrong value for {{Statement.getUpdateCount()}} and indicates that
> additional results are available.
> The JavaDoc for {{java.sql.Statement#getMoreResults(int)}} says there are no
> more results when the following is true:
> {code:java}
> // stmt is a Statement object
> ((stmt.getMoreResults(current) == false) && (stmt.getUpdateCount() == -1))
> {code}
> In {{{}AvaticaStatement{}}}, {{getMoreResults(int)}} always returns {{false}}
> to indicate there are no more {{ResultSet}} objects, but does not reset the
> {{updateCount}} which can indicate that there was an additional result (but
> that's not true). Since the JavaDoc states that clients should call both
> {{getMoreResults}} and {{getUpdateCount}} to determine if there are more
> results, any client that has the above Java code in a while loop would never
> reach an exit condition resulting in an infinite loop.
> *Steps to reproduce:*
> # Execute an INSERT query by calling Statement#execute(String). Verify that
> the return value is false indicating it is an update count.
> # Call Statement#getMoreResults(). Verify that the return value is false
> indicating it is an update count or there are no more results.
> # Call Statement#getUpdateCount().
> *Expected results:*
> The call to getUpdateCount() returns -1 indicating there are no more results.
> *Actual results:*
> The call to getUpdateCount() returns the update count for the INSERT query,
> which should only have one result.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
