[
https://issues.apache.org/jira/browse/CALCITE-712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14533773#comment-14533773
]
Xavier FH Leong edited comment on CALCITE-712 at 5/8/15 2:45 AM:
-----------------------------------------------------------------
:D, not finding finger to point, but just illustrate the logic flow.
{quote}
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?
{quote}
No, if setting the maxRowCount will do a re-prepare, the execute will always
get the latest settings (plus a new statement at the server end), so the above
scenario would not happen.
{quote}
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.
{quote}
I think what missing here is that we are trying to set the maxRowCount during
prepare, instead of during execute. To fulfill JDBC contract for setting
maxRowCount, even for PreparedStatment, I think is good to support RPC call
that can
* prepare
* execute
* prepareAndExecute
prepareAndExecute can end up calling prepare and then execute, we can also
choose to combine the call and indicating which task under the method argument,
but I prefer having separate RPC which is much cleaner.
{quote}
I found at least one place where you were checking 'parameter > 0'
{quote}
I think that would be in the JdbcMeta.prepare, the original check is in
prepareAndExecute, where maxRowCount has been change by following code:
{code}
// In JDBC, maxRowCount = 0 means no limit; in prepare it means LIMIT 0
final int maxRowCount1 = maxRowCount <= 0 ? -1 : maxRowCount;
{code}
But I agree, prepare should takes 0, but for JdbcMeta.prepare case it is
checking condition whether to call setMaxRows, not to pass in for meta.prepare.
Should the above code be in setMaxRows instead of having to convert in every
execute call?
was (Author: xhoong):
:D, not finding finger to point, but just illustrate the logic flow.
> 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?
No, if setting the maxRowCount will do a re-prepare, the execute will always
get the latest settings (plus a new statement at the server end), so the above
scenario would not happen.
>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.
I think what missing here is that we are trying to set the maxRowCount during
prepare, instead of during execute. To fulfill JDBC contract for setting
maxRowCount, even for PreparedStatment, I think is good to support RPC call
that can
* prepare
* execute
* prepareAndExecute
prepareAndExecute can end up calling prepare and then execute, we can also
choose to combine the call and indicating which task under the method argument,
but I prefer having separate RPC which is much cleaner.
> I found at least one place where you were checking 'parameter > 0'
I think that would be in the JdbcMeta.prepare, the original check is in
prepareAndExecute, where maxRowCount has been change by following code:
```
// In JDBC, maxRowCount = 0 means no limit; in prepare it means LIMIT 0
final int maxRowCount1 = maxRowCount <= 0 ? -1 : maxRowCount;
```
But I agree, prepare should takes 0, but for JdbcMeta.prepare case it is
checking condition whether to call setMaxRows, not to pass in for meta.prepare.
Should the above code be in setMaxRows instead of having to convert in every
execute call?
> 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)
