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() method.
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. Thanks, James On Tue, Jul 28, 2015 at 10:40 PM, Anchal Agrawal <[email protected]> wrote: > 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" > DATA_TYPE_HERE);* > > 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 > <https://phoenix.apache.org/language/datatypes.html#unsigned_long_type> > 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 >
