phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William Yang (JIRA)" <>
Subject [jira] [Commented] (PHOENIX-3335) long type in hbase mapping pheonix type error
Date Tue, 27 Sep 2016 11:13:20 GMT


William Yang commented on PHOENIX-3335:

This is exactly how it works. see
BIGINT is a signed data type. As you know, the first bit of a negative value is 1, but positive
value 0. So negative values will be 'greater than' positive values in dictionary order. In
order to let all values sorted in the right way, PHOENIX flip the first bit for signed values,
so that negative values will sort before positive values. But for unsigned types, this is
not needed.

So, this is not a bug. If you want to map hbase table to phoenix, make sure that your are
using unsigned types for integers.

> long type in hbase mapping pheonix type error
> ---------------------------------------------
>                 Key: PHOENIX-3335
>                 URL:
>             Project: Phoenix
>          Issue Type: Improvement
>    Affects Versions: 4.8.0
>            Reporter: Kui Xiang
> when i use the function of increament in hbase 2.0.x
> push a value like '\x00\x00\x00\x00\x00\x00\x00\x01' in hbase 
> then i create pheonix table like:
> <pre>
> create table click_pv(pk varchar primary key,"default"."min_time" VARCHAR,"default"."pid"
VARCHAR,"default"."pv" BIGINT);
> </pre>
> the pv column 's type use BIGINT will mapping the value to -9223372036854775805
> and when i use UNSIGNED_LONG type ,it will works ok.
> it looks a little strange..

This message was sent by Atlassian JIRA

View raw message