[ 
https://issues.apache.org/jira/browse/CALCITE-871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14945169#comment-14945169
 ] 

Josh Elser commented on CALCITE-871:
------------------------------------

[Bruno's 
Patch|https://issues.apache.org/jira/secure/attachment/12765179/0001-Avatica-fix-remote-columns-iterations.patch]
 which applies on top of CALCITE-912

> 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: Josh Elser
>             Fix For: 1.5.0-incubating
>
>
> 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)

Reply via email to