[
https://issues.apache.org/jira/browse/CALCITE-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15095510#comment-15095510
]
Julian Hyde commented on CALCITE-1044:
--------------------------------------
I think JDBC got it wrong. It makes sense to execute a query with a maxRowCount
of 0. The execute still happens. You get to find out whether execute produces
an error, and in the case of Drill (which is schema-on-query) you find out the
true row schema.
> 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)
