phoenix-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthew Johnson <matt.john...@algomi.com>
Subject RE: BigDecimal casting issue?
Date Thu, 26 Feb 2015 14:39:43 GMT
Thanks guys,



Unfortunately I cannot easily change the way the value is serialized into
HBase because that value is used by multiple other projects that don’t use
Phoenix. Over time I could potentially migrate all these projects but I was
hoping for a slightly more immediate solution. I could write an overnight
batch job that scans through the entire table, and for every value that is
a BigDecimal I could duplicate it into a new column with the PDataType
Decimal, but this seems kinda inefficient and would duplicate a lot of data.



I had a look at the documentation (and tried a few combinations) but could
not find an UNSIGNED_DECIMAL type for Phoenix.



Is there any other way I can retrieve BigDecimal values with Phoenix? If I
wanted to write my own wrapper for Phoenix that supports BigDecimal, would
I have to patch just the client or would I have to patch the server as well?



Cheers,

Matt





*From:* anil gupta [mailto:anilgupta84@gmail.com]
*Sent:* 26 February 2015 13:44
*To:* user@phoenix.apache.org
*Subject:* Re: BigDecimal casting issue?



Hi Matthew,

If you want phoenix to read a BigDecimal value out of HBase. You will need
to use PDataType.DECIMAL.toBytes(BigDecimal) to serialize that value in
HBase. IMO, serialization of of BigDecimal via PDataType is better because
it enables byte array comparison on BigDecimal values.

Thanks,

Anil



On Thu, Feb 26, 2015 at 4:30 AM, Gabriel Reid <gabriel.reid@gmail.com>
wrote:

Hi Matt,

Although the object representation of the Phoenix DECIMAL type is
BigDecimal, the byte-level encoding is different than that of
Bytes.toBytes(BigDecimal). The reason for this is to allow for
ordering of these values based comparison of binary values. Sorting
the values with binary value comparison based on the return value of
Bytes.toBytes(BigDecimal) will not result in the correct ordering of
values.

As you may have noticed, many data types in Phoenix have an UNSIGNED_*
counter part which uses the same underlying encoding as Bytes.toBytes,
although these datatypes suffer from the same binary comparison issue
as outlined above.

- Gabriel




On Thu, Feb 26, 2015 at 12:06 PM, Matthew Johnson
<matt.johnson@algomi.com> wrote:
> Hi all,
>
>
>
> I am trying to map an HBase column where I store java.math.BigDecimal
values
> using:
>
>
>
> Bytes.toBytes(myBigDecimalValueInJava)
>
>
>
> My understanding from the “Data Types” page
> (http://phoenix.apache.org/language/datatypes.html#decimal_type) is that
the
> DECIMAL type in Phoenix should map to this. However, when I store:
>
>
>
> 102.1
>
>
>
> in HBase, Phoenix reads it back as:
>
>
>
> -1.02020201E+126
>
>
>
> Not sure whether I am using it wrong? I have tried creating the view with
> data type DECIMAL and also DECIMAL(15,5) but both give the same problem.
Is
> anyone else able to successfully insert BigDecimal values via the HBase
> client and retrieve them using Phoenix?
>
>
>
> FYI when I retrieve the value using HBase client:
>
>
>
> BigDecimal bd = Bytes.toBigDecimal(value);
>
>
>
> It correctly prints the value of 102.1.
>
>
>
> Any thoughts?
>
>
>
> Cheers,
>
> Matt
>
>
>
>




-- 

Thanks & Regards,
Anil Gupta

Mime
View raw message