[
https://issues.apache.org/jira/browse/CALCITE-1254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15308781#comment-15308781
]
Josh Elser commented on CALCITE-1254:
-------------------------------------
bq. I figured that if someone was asking for at most N rows then clearly there
could be no more than N rows in the first frame. Given that cap, I can't
imagine a scenario where an existing client would see a change in behavior.
Read this too fast the first time. You're entirely right. I didn't think that
through the whole way -- just saw the -1 and thought that users might get more
results than they did previously.
> Support PreparedStatement.executeLargeBatch
> -------------------------------------------
>
> Key: CALCITE-1254
> URL: https://issues.apache.org/jira/browse/CALCITE-1254
> Project: Calcite
> Issue Type: Bug
> Components: avatica
> Reporter: Julian Hyde
> Assignee: Josh Elser
> Priority: Blocker
> Fix For: avatica-1.8.0
>
>
> In CALCITE-1128 we added support for PreparedStatement.executeBatch. This
> added ExecuteBatchResult with a field {{int[] updateCounts}}.
> I think that field should have been {{long[]}} instead. Elsewhere we have
> been converting update counts from {{int}} to {{long}}, in line with changes
> to the JDBC API.
> If changing this field from {{int[]}} to {{long[]}} will be a breaking change
> we should consider halting 1.8 to get this in.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
