[ 
https://issues.apache.org/jira/browse/PHOENIX-4382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16299313#comment-16299313
 ] 

Thomas D'Silva edited comment on PHOENIX-4382 at 12/21/17 12:34 AM:
--------------------------------------------------------------------

In the old IMMUTABLE_STORAGE_SCHEME we stored null values as {separatorByte, # 
of nulls}. This was not correct as its possible the data type of the column 
values being stored could be fixed length. We don't need to represent null 
values this way since they can just be derived from the offset array. 


was (Author: tdsilva):
In the old IMMUTABLE_STORAGE_SCHEME when there we stored null values as 
{separatorByte, # of nulls}. This was not correct as its possible the data type 
of the column values being stored could be fixed length. We don't need to 
represent null values this way since they can just be derived from the offset 
array. 

> 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, 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)

Reply via email to