[
https://issues.apache.org/jira/browse/CALCITE-871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14972592#comment-14972592
]
Bruno Dumon commented on CALCITE-871:
-------------------------------------
[~elserj], yes of course, go ahead.
> JdbcResultSet returns incomplete Frame with "default" statement ID
> ------------------------------------------------------------------
>
> Key: CALCITE-871
> URL: https://issues.apache.org/jira/browse/CALCITE-871
> Project: Calcite
> Issue Type: Bug
> Components: avatica
> Affects Versions: 1.4.0-incubating
> Reporter: Josh Elser
> Assignee: Bruno Dumon
> Fix For: 1.5.0
>
>
> I noticed this case while playing around with sqlline, phoenix queryserver
> and avatica.
> When sqlline starts up, it, among other things, fetches the columns to do
> some autocompletion magic in its shell. I noticed that this was always
> resulting in an error in Avatica's code, saying that the statement id wasn't
> found (the "fake" one {{-1}})
> I traced through this and believe there's a problem with how JdbcResultSet
> computes the maximum size of results put into a Frame. For the calls which
> use this fake statement id (getColumns, getCatalogs, getTableTypes, etc), a
> result set returned by the wrapped JDBC driver which is larger than 100
> results will cause a Frame to be sent back to the client which informs it to
> fetch another frame (via the {{done}} member).
> Concretely, if there are more than 100 columns to return in getColumns, the
> client will receive a Frame with {{done=false}} and 100 rows which will cause
> it to try to fetch another Frame of results. This will fail because we gave a
> fake statement ID which causes an exception in the server.
> As I see it, there are two solutions:
> # Create and cache a statement on these calls so that the fetch logic works
> as intended (the good solution)
> # Send all of the results back in one frame (the quick hacky thing I just
> tested).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
