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

["Julian Hyde (JIRA)" <ji...@apache.org>]

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

Julian Hyde commented on CALCITE-927:
-------------------------------------

Fixed in http://git-wip-us.apache.org/repos/asf/incubator-calcite/commit/afd7e2e2. [~elserj], Thanks for the patch!

No, it's better to do as you did, and fix finagle.

If the result is of type Xxx you had better use an XxxAccessor. Not create a YyyAccessor and fix it up to deal with all possible results. Hence my push-back on CALCITE-921.

> 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: 1.5.0-incubating
>
>
> 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)