[ 
https://issues.apache.org/jira/browse/CALCITE-871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Hyde reassigned CALCITE-871:
-----------------------------------

    Assignee: Bruno Dumon  (was: Josh Elser)

[~bruno], I've given you contributor privileges and assigned the issue to you.

Can you please start using pull requests rather than patches? Then you won't 
need to say "this is based on ...". Also, it will be easier for others to 
rebase if a contribution is under development for a long time.

> 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-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