[
https://issues.apache.org/jira/browse/PHOENIX-4382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Poon updated PHOENIX-4382:
----------------------------------
Attachment: PHOENIX-4382.v1.master.patch
This turned out to be a column encoding bug. The data is written fine but when
reading, in PArrayDataTypeDecoder there is an optimization that checks for
SEPARATOR_BYTE in the first byte - if it's there, it is assumed the value
length is 0. This makes sense in SORTABLE_SERIALIZATION, but for
IMMUTABLE_SERIALIZATION, there are no separators. If the data just happens to
have a first byte of 0 or -1 (SEPARATOR_BYTE or DESC_SEPARATOR_BYTE), then the
optimization does the wrong thing. For short values > 32511, the first byte is
-1, which is why this bug was appearing.
The fix is to not do the optimization for IMMUTABLE_SERIALIZATION.
[~tdsilva] can you review ?
FYI, [~jamestaylor] [~aertoria]
> Upsert of some big values not correct for immutable tables
> ----------------------------------------------------------
>
> 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, 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. Numbers smaller than that
> are fine (until you get closer to Short.MIN_VALUE...)
> See attached test - testShort() , testBigInt()
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
