phoenix-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Taylor <>
Subject Re: Signed long values in column
Date Wed, 29 Jul 2015 15:43:17 GMT
Hi Anchal,
Phoenix depends on the sort order of the serialized bytes to match the
natural sort order of the column value. The HBase Bytes.toBytes() methods
do not meet this requirement, as negative numbers will sort ahead of
positive numbers. About the only option you have in this case is to create
a new Phoenix table and copy the data over from your old table. If the data
is being created by some external process, then you'd need to change it to
use the PDataType toBytes() method instead of the HBase Bytes.toBytes()

It's possible that Phoenix could relax this constraint for columns that are
not part of the primary key constraint - please file a JIRA for this. We'd
need to define a new PDataType (it could share almost all of it's
implementation with PUnsignedLong) and handle ORDER BY differently for
these types.


On Tue, Jul 28, 2015 at 10:40 PM, Anchal Agrawal <>

> Hi,
> I'm creating a Phoenix view of an existing HBase table on v4.4.0.
> Command: *CREATE VIEW "table_name" (pk VARBINARY PRIMARY KEY, "cf"."col"
> The *col* column has long values that are serialized by
> Bytes.toBytes(long) but since some values are negative, I can't use
> UNSIGNED_LONG. I tried BIGINT instead since the documentation says that it
> maps to java.lang.Long, but that resulted in incorrect column values. The datatype
> documentation
> <>
> for UNSIGNED_LONG says "use the regular signed type instead" - which
> datatype is this referring to? LONG isn't supported.
> I could create the view with the column values as bytearrays and write a
> UDF to extract long values, but I think that will add to the latency. Is
> there a way around this? I really appreciate your help.
> Sincerely,
> Anchal Agrawal

View raw message