[
https://issues.apache.org/jira/browse/PHOENIX-652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Taylor updated PHOENIX-652:
---------------------------------
Summary: Use new type system bundled with HBase (was: Use new type system
in HBase 0.96)
> Use new type system bundled with HBase
> --------------------------------------
>
> Key: PHOENIX-652
> URL: https://issues.apache.org/jira/browse/PHOENIX-652
> Project: Phoenix
> Issue Type: Task
> Reporter: James Taylor
>
> A new type system that maintains the row order lexiographically was
> introduced in HBase 0.96 in
> [HBase-8089](https://issues.apache.org/jira/browse/HBASE-8089). We should try
> to have Phoenix use this type system instead of it's own.
> Couple of open questions:
> * How will performance be affected?
> * Are there gaps in functionality that need to be addressed.
> * One gap may be in getting the next/previous key of a compound row key
> (see ByteUtil.nextKey(byte[] key) and ByteUtil.previousKey(byte[] key)).
> The biggest advantage to switch would be to get better interop with existing
> products such as Hive and in general with HBase applications who adopt this
> type system. In this case, Phoenix can potentially be used directly against
> existing HBase data, greatly increasing the use case for [mapping to an
> existing HBase
> table](https://github.com/forcedotcom/phoenix/wiki_mapping-to-an-existing-hbase-table)
> Another advantage would be in simplifying when we have to coerce values
> "under-the-covers" since fixed width types do not have a representation for
> null in the existing type system. We do this conversion when a GROUP BY is
> done as well as when an index is created over any fixed width type (by
> coercing automatically between INTEGER and DECIMAL, for example). The new
> type system has a consistent representation for null, so this would
> potentially not be required.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
