[
https://issues.apache.org/jira/browse/CALCITE-718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14562222#comment-14562222
]
Xavier FH Leong commented on CALCITE-718:
-----------------------------------------
I have started looking into this, the main reason is that when the frame is
created in JdbcResultSet, it is hardcoded to all rows (-1), that can change to
in sync with FetchIterable value which is 100.
However, there's also a logic flow problem, in Avatica, every createStatement
call is also RPC to the server, but the remote statement originally created was
never used, and each call to Statement.execute() will actually create a brand
new statement, hence the statement ID on remote vs local is out of sync during
fetch. I plan to modify the parameter for prepareAndExecute to use
StatementHandle instead of ConnectionHandle (where it store both the connection
and statement ID) to recover the previous created statement.
Currently, the statement and connection cache are remain separate, I see a
problem during invalidation of cache if they are kept apart, connection may
close first before statement and making statement retrieved from statement
cache being staled. One way is to extend the connection cache to include data
structure that also store statement map, and there only remain a single cache
policy. This is most likely a separate issue from this JIRA.
> Enable fetch to work for Statement.execute()
> --------------------------------------------
>
> Key: CALCITE-718
> URL: https://issues.apache.org/jira/browse/CALCITE-718
> Project: Calcite
> Issue Type: Improvement
> Reporter: Xavier FH Leong
> Assignee: Julian Hyde
> Priority: Minor
> Labels: avatica
>
> Current Avatica Statement.execute() will build the complete result set before
> sending back to client, enable fetch to send only max fetch rows.
> Reference discussion: CALCITE-712
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
