[ https://issues.apache.org/jira/browse/PHOENIX-4382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16304113#comment-16304113 ]
James Taylor commented on PHOENIX-4382: --------------------------------------- bq. Should we add a config option to determine the behavior when we see a {separatorByte, 1} ? Not sure we need this. Probably more likely it’d be null as opposed to -32,767. A global config won’t help much since it could be different on table by table or column by column basis. +1 for a few more comments. > 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 > Attachments: PHOENIX-4382.v1.master.patch, > PHOENIX-4382.v2.master.patch, PHOENIX-4382.v3.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)