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/09/09 08:45:29 UTC

[jira] [Commented] (PHOENIX-1244) Not Null primary key with SEPEARTOR_BYTE does not get retrieved in the result set.

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

James Taylor commented on PHOENIX-1244:
---------------------------------------

You'll need to breakup the full table name to its constituent parts by change TABLE_NAME to TENANT_ID, SCHEMA_NAME, and TABLE_NAME in the create table statement.

> Not Null primary key with SEPEARTOR_BYTE does not get retrieved in the result set.
> ----------------------------------------------------------------------------------
>
>                 Key: PHOENIX-1244
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-1244
>             Project: Phoenix
>          Issue Type: Bug
>            Reporter: ramkrishna.s.vasudevan
>
> We have a table with the below primary key
> {code}
> "CREATE TABLE " + SYSTEM_CATALOG_SCHEMA + ".\"" + SYSTEM_STATS_TABLE + "\"(\n" +
>             // PK columns
>             TABLE_NAME  + " VARCHAR NOT NULL," +
>             COLUMN_NAME + " VARCHAR," +
>             REGION_NAME + " VARCHAR," +
> {code}
> Now the table name is formed using the tenanid and schema id.  But as the tenant id and schema id are null for non-tenant specific cases the table name will have the SEPERATOR_BYTE appended to it (using SchemaUtil.getTableKey).  In such cases when we try to do a a SELECT on the table_name and do rs.getString(), we are able to access the table name but when we try to get the length of the row key in RowkeyValueAccessor.getLength
> {code}
> public int getLength(byte[] keyBuffer, int keyOffset, int maxOffset) {
>         if (!hasSeparator) {
>             return maxOffset - keyOffset;
>         }
>         int offset = keyOffset;
>         // FIXME: offset < maxOffset required because HBase passes bogus keys to filter to position scan (HBASE-6562)
>         while (offset < maxOffset && keyBuffer[offset] != SEPARATOR_BYTE) {
>             offset++;
>         }
>         return offset - keyOffset;
>     }
> {code}
> because we find a SEPEARTOR_BYTE in the table name[] we tend to return 0 as the table length.  Should these cases handled specifically?



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