[
https://issues.apache.org/jira/browse/PHOENIX-1244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14126695#comment-14126695
]
James Taylor edited comment on PHOENIX-1244 at 9/9/14 6:46 AM:
---------------------------------------------------------------
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. A VARCHAR may not contain a null byte.
was (Author: jamestaylor):
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)
