You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@phoenix.apache.org by "James Taylor (JIRA)" <ji...@apache.org> on 2018/01/22 20:54:00 UTC
[jira] [Updated] (PHOENIX-4382) Immutable table
SINGLE_CELL_ARRAY_WITH_OFFSETS values starting with separator byte return
null in query results
[ https://issues.apache.org/jira/browse/PHOENIX-4382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
James Taylor updated PHOENIX-4382:
----------------------------------
Fix Version/s: 4.13.2
> Immutable table SINGLE_CELL_ARRAY_WITH_OFFSETS values starting with separator byte 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
> Priority: Major
> Fix For: 5.0, 4.14.0, 4.13.2, 4.13.2-cdh5.11.2
>
> Attachments: PHOENIX-4382.v1.master.patch, PHOENIX-4382.v2.master.patch, PHOENIX-4382.v3.master.patch, PHOENIX-4382.v4.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
(v7.6.3#76005)