Mailing-List: contact dev-help@phoenix.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@phoenix.incubator.apache.org
Date: Fri, 2 May 2014 04:56:14 +0000 (UTC)
From: "James Taylor (JIRA)" <jira@apache.org>
To: dev@phoenix.incubator.apache.org
Message-ID: <JIRA.12700424.1394495273941.217635.1399006574574@arcas>
In-Reply-To: <JIRA.12700424.1394495273941@arcas>
References: <JIRA.12700424.1394495273941@arcas>
Subject: [jira] [Updated] (PHOENIX-652) Use new type system bundled with
 HBase
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ 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)