[
https://issues.apache.org/jira/browse/PHOENIX-4382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Poon updated PHOENIX-4382:
----------------------------------
Description:
For immutable tables, upsert of some values like Short.MAX_VALUE results in a
null value in query resultsets. Mutable tables are not affected. I tried with
BigInt and got the same problem.
For Short, the breaking point seems to be 32512.
This is happening because of the way we serialize nulls. For nulls, we write
out [separatorByte, #_of_nulls]. However, some data values, like
Short.MAX_VALUE, start with separatorByte, we can't distinguish between a null
and these values. Currently the code assumes it's a null when it sees a
leading separatorByte, hence the incorrect query results.
See attached test - testShort() , testBigInt()
was:
For immutable tables, upsert of some values like Short.MAX_VALUE results in a
null value in query resultsets. Mutable tables are not affected. I tried with
BigInt and got the same problem.
For Short, the breaking point seems to be 32512. Numbers smaller than that are
fine (until you get closer to Short.MIN_VALUE...)
See attached test - testShort() , testBigInt()
> Certain immutable table variable length column values may return null in
> query results
> --------------------------------------------------------------------------------------
>
> Key: PHOENIX-4382
> URL: https://issues.apache.org/jira/browse/PHOENIX-4382
> Project: Phoenix
> Issue Type: Bug
> Affects Versions: 4.14.0
> Reporter: Vincent Poon
> Assignee: Vincent Poon
> Attachments: PHOENIX-4382.v1.master.patch,
> PHOENIX-4382.v2.master.patch, UpsertBigValuesIT.java
>
>
> For immutable tables, upsert of some values like Short.MAX_VALUE results in a
> null value in query resultsets. Mutable tables are not affected. I tried
> with BigInt and got the same problem.
> For Short, the breaking point seems to be 32512.
> This is happening because of the way we serialize nulls. For nulls, we write
> out [separatorByte, #_of_nulls]. However, some data values, like
> Short.MAX_VALUE, start with separatorByte, we can't distinguish between a
> null and these values. Currently the code assumes it's a null when it sees a
> leading separatorByte, hence the incorrect query results.
> See attached test - testShort() , testBigInt()
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
