[
https://issues.apache.org/jira/browse/PHOENIX-4283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16205268#comment-16205268
]
Ethan Wang commented on PHOENIX-4283:
-------------------------------------
Yes, when cut off happens, the "actualType" is Decimal, "this" is BigInt. The
"actualType" is pass from RowKeyColumnExpression.fromType, which is Decimal in
nested groupby. So, as comparison, in RowKeyColumnExpression,
logic : type.coerceBytes(ptr, fromType);
*nested*: BIGINT.coerceBytes(ptr, DECIMAL);
*normal*: BIGINT.coerceBytes(ptr, BIGINT);
I think the issue may be that, in PLong, coerceBytes() is override *regardless*
the "actualType", before passing into super.coerceBytes(). Therefore, the cut
off get executed always.
{code} @Override
public void coerceBytes(ImmutableBytesWritable ptr, Object object,
PDataType actualType,
Integer maxLength, Integer scale, SortOrder actualModifier, Integer
desiredMaxLength, Integer desiredScale,
SortOrder expectedModifier) {
// Decrease size of TIMESTAMP to size of LONG and continue coerce
if (ptr.getLength() > getByteSize()) {
ptr.set(ptr.get(), ptr.getOffset(), getByteSize());
}
super.coerceBytes(ptr, object, actualType, maxLength, scale,
actualModifier, desiredMaxLength,
desiredScale, expectedModifier);
}
{code}
> 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)
