[
https://issues.apache.org/jira/browse/PHOENIX-1244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14126703#comment-14126703
]
James Taylor commented on PHOENIX-1244:
---------------------------------------
Actually, just SCHEMA_NAME and TABLE_NAME. I don't think it makes sense to have
TENANT_ID. The client may be allowed to do an ANALYZE on a tenant-specific
connection, but that would just affect the range over which we're re-generating
the stats. The stats table will always be dealing with a *physical* table, so
TENANT_ID doesn't make sense to have in the schema (as it would always be null).
> 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)
