[
https://issues.apache.org/jira/browse/CALCITE-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15095210#comment-15095210
]
Josh Elser commented on CALCITE-1044:
-------------------------------------
[~julianhyde] can I get your opinion here? I thought it was silly that we would
accept a maxRowCount=0 on the server for a query, but I do see that we have a
test for that specific case.
Is there a reason that we should retain this functionality?
> Quirky handling of PrepareAndExecuteRequests maxRowCount attribute
> ------------------------------------------------------------------
>
> Key: CALCITE-1044
> URL: https://issues.apache.org/jira/browse/CALCITE-1044
> Project: Calcite
> Issue Type: Bug
> Components: avatica
> Affects Versions: 1.5.0
> Reporter: Carter Shanklin
> Assignee: Josh Elser
> Fix For: 1.6.0
>
>
> Another good find sent to me by [~cartershanklin].
> He noticed when using the Protobuf wire API directly, provided a value of 0
> for {{maxRowCount}} in a {{PrepareAndExecuteRequest}} resulted in no values
> being returned.
> I dug around a little and found this little tweak done:
> {panel:title=AvaticaStatement.java}
> {code}
> protected void executeInternal(String sql) throws SQLException {
> // reset previous state before moving forward.
> this.updateCount = -1;
> try {
> // In JDBC, maxRowCount = 0 means no limit; in prepare it means LIMIT 0
> final long maxRowCount1 = maxRowCount <= 0 ? -1 : maxRowCount;
> for (int i = 0; i < connection.maxRetriesPerExecute; i++) {
> try {
> Meta.ExecuteResult x =
> connection.prepareAndExecuteInternal(this, sql, maxRowCount1);
> {code}
> {panel}
> It would be nice to also do this correction on the server side to get this
> behavior since our wire API so closely matches the JDBC API.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
