[
https://issues.apache.org/jira/browse/CALCITE-5443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-5443:
---------------------------------
Description:
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.
was:
After {{java.sql.Statement.getMoreResults()}} has returned false,
{{Statement.getUpdateCount()}} should return {{{}-1{}}}. This indicates to the
client that there are no additional result sets available. Calcite currently
supports at most one result set per SQL statement.
*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.
> 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
> Fix For: avatica-1.23.0
>
> Time Spent: 10m
> 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)
