[ 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)