phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Taylor (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (PHOENIX-4283) Group By statement truncating BIGINTs
Date Sun, 15 Oct 2017 17:01:11 GMT

    [ https://issues.apache.org/jira/browse/PHOENIX-4283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16205199#comment-16205199
] 

James Taylor edited comment on PHOENIX-4283 at 10/15/17 5:00 PM:
-----------------------------------------------------------------

bq. a byte array operation mistakenly cutting a serialized DECIMAL ImmutableBytesWritable
from 11B to 8B, dropping 3B in the tail, which responsible for 6 last digits data loss. This
cut-off happened at PLong.coerceBytes() when it try to "Decrease size of TIMESTAMP to size
of LONG and continue coerce".
Need to figure out why it’s decreasing size here. Sounds like Phoenix thinks the underlying
type is a long instead of a decimal (based on the truncation to 8 bytes, the size of a long).
Does it have decimal as the actualType in the method? I think if you compare the non nested
coercions (which are correct) to the nested coercions, you may be able to spot this particular
issue.


was (Author: jamestaylor):
bq. a byte array operation mistakenly cutting a serialized DECIMAL ImmutableBytesWritable
from 11B to 8B, dropping 3B in the tail, which responsible for 6 last digits data loss. This
cut-off happened at PLong.coerceBytes() when it try to "Decrease size of TIMESTAMP to size
of LONG and continue coerce".
Need to figure out why it’s decreasing size here. Sounds like Phoenix thinks the underlying
type is a long instead of a decimal (based on the truncation to 8 bytes, the size of a long).
Does it have decimal as the actualType in the method?

> Group By statement truncating BIGINTs
> -------------------------------------
>
>                 Key: PHOENIX-4283
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-4283
>             Project: Phoenix
>          Issue Type: Bug
>    Affects Versions: 4.11.0
>            Reporter: Steven Sadowski
>            Assignee: Ethan Wang
>             Fix For: 4.12.1
>
>
> *Versions:*
> Phoenix 4.11.0
> HBase: 1.3.1
> (Amazon EMR: 5.8.0)
> *Steps to reproduce:*
> 1. From the `sqlline-thin.py` client setup the following table:
> {code:sql}
> CREATE TABLE test_table (
>     a BIGINT NOT NULL, 
>     c BIGINT NOT NULL
>     CONSTRAINT PK PRIMARY KEY (a, c)
> );
> UPSERT INTO test_table(a,c) VALUES(4444444444444444444, 5555555555555555555);
> SELECT a FROM (SELECT a, c FROM test_table GROUP BY a, c) GROUP BY a, c;
> {code}
> *Expected Result:*
> {code:sql}
> +----------------------+
> |          A           |
> +----------------------+
> | 4444444444444444444  |
> +----------------------+
> {code}
> *Actual Result:*
> {code:sql}
> +----------------------+
> |          A           |
> +----------------------+
> | 4444444444444000000  |
> +----------------------+
> {code}
> *Comments:*
> Having the two Group By statements together seems to truncate the last 6 or so digits
of the final result. Removing the outer (or either) group by will produce the correct result.
> Please fix the Group by statement to not truncate the outer result's value.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message