[
https://issues.apache.org/jira/browse/CALCITE-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15095538#comment-15095538
]
Josh Elser commented on CALCITE-1044:
-------------------------------------
bq. 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.
Oh interesting. I hadn't thought about that. That makes sense. I think this is
a close as won't-fix then.
> 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
>
> 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)
