[
https://issues.apache.org/jira/browse/CALCITE-712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14533371#comment-14533371
]
Julian Hyde commented on CALCITE-712:
-------------------------------------
I've reviewed this. I agree that it's quite messy, and not your fault. I think
the root cause is the fact that a prepare call can specify the maxRowCount and
if that prepared statement is re-executed with a higher maxRowCount (or no
limit) the results will be invalid. Do you agree with the root cause?
I think re-preparing a prepared statement is unacceptable.
I believe that the only time a prepare request occurs with a row limit is a
prepare-and-execute call (i.e. caused by Statement.executeQuery). Do you
believe that to be true? If that is true, then it will be impossible to
re-execute the prepare with a different row limit. If we can put in place an
assert that will make sure that this is true, I think we can avoid the
re-prepare.
I found at least one place where you were checking 'parameter > 0' where the
javadoc comment on the parameter said 'negative means no limit'. 0 is not
negative. Please be careful.
> Avatica statement execute return all resultset instead of MaxRows from
> setMaxRows
> ---------------------------------------------------------------------------------
>
> Key: CALCITE-712
> URL: https://issues.apache.org/jira/browse/CALCITE-712
> Project: Calcite
> Issue Type: Bug
> Affects Versions: 1.3.0-incubating
> Reporter: Xavier FH Leong
> Assignee: Julian Hyde
> Labels: avatica
>
> setMaxRows is supported, but after moving to JdbcMeta, max row was ignore and
> full result set is return instead.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
