You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@phoenix.apache.org by "James Taylor (JIRA)" <ji...@apache.org> on 2014/03/07 04:00:45 UTC

[jira] [Commented] (PHOENIX-116) Phoenix array integer types overlap with existing java.sql.Types

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

James Taylor commented on PHOENIX-116:
--------------------------------------

+1. Good catch, [~gabriel.reid], thanks. [~ram_krish] - would you mind applying the patch? Might need to be re-based, [~gabriel.reid], as there was biggish change that went in after this.

> Phoenix array integer types overlap with existing java.sql.Types
> ----------------------------------------------------------------
>
>                 Key: PHOENIX-116
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-116
>             Project: Phoenix
>          Issue Type: Bug
>            Reporter: Gabriel Reid
>            Assignee: ramkrishna.s.vasudevan
>             Fix For: 3.0.0
>
>         Attachments: PHOENIX-116.patch
>
>
> The type value returned for Phoenix typed arrays are currently created by taking the sum of java.sql.Types.ARRAY and the sql type of the element type. However, this causes some collisions with existing java.sql.Types values.
> For example, the SQL type value for BINARY_ARRAY is the value of Types.ARRAY + Types.BINARY, which is 2003 + (-2), or 2001. 2001 is an existing constant for java.sql.Types.DISTINCT. 
> There is also a collision with java.sql.Types.BLOB and PDataTypes.CHAR_ARRAY.getSqlType().
> Next to the fact that these collisions occur, there's probably not much reason to base the SQL types for typed arrays on the java.sql.Types.ARRAY constant, as I assume that external tooling won't be aware of this convention anyhow.



--
This message was sent by Atlassian JIRA
(v6.2#6252)