You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Josh Elser (JIRA)" <ji...@apache.org> on 2015/10/20 04:40:27 UTC

[jira] [Updated] (CALCITE-927) ColumnsRequest Service call doesn't "fix" ResultSetResponse.

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

Josh Elser updated CALCITE-927:
-------------------------------
    Summary: ColumnsRequest Service call doesn't "fix" ResultSetResponse.  (was: ColumnsRequest doesn't "fix" ResultSetResponse.)

> ColumnsRequest Service call doesn't "fix" ResultSetResponse.
> ------------------------------------------------------------
>
>                 Key: CALCITE-927
>                 URL: https://issues.apache.org/jira/browse/CALCITE-927
>             Project: Calcite
>          Issue Type: Bug
>          Components: avatica
>            Reporter: Josh Elser
>            Assignee: Josh Elser
>             Fix For: next
>
>
> Was finally trying to get to the bottom of PHOENIX-1972. Ultimately stumbled onto the subtlety that the ResultSetResponse from ColumnsRequest isn't run through {{finagle}}.
> I believe this ultimately causes the ColumnMetaData to be of {{Types.BIGINT}} and {{Rep.PRIMITIVE_LONG}} instead of {{Types.BIGINT}} and {{Rep.NUMBER}}.
> This ultimately pushes us to the LongAccessor instead of the NumberAccessor (which is really the BigNumberAccessor) that correctly handles the "cast" from an Integer to a Long that the LongAccessor does not.
> My only concern so far is that I haven't also been able to get this happen via hsqldb in a test. I've only been able to verify it via Phoenix.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)