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

James Taylor commented on PHOENIX-4382:
---------------------------------------

[~vincentpoon] - thanks for following up on this one. I'd like to understand 
how serious the problem is:
- Will the problem potentially occur for a schema when a variable length field 
is followed by a fixed length field like: VARCHAR + BIGINT?
- In the old scheme, do we only write the separator byte for a variable length 
column or do we write a separator byte after fixed length columns too? Or are 
we only writing a separator byte when the column is null?
- I remember we tried to optimize storage by not writing a zero byte for every 
contiguous field that was null. Do we do this even if there's a single null 
column (i.e. writing a zero byte plus another byte)?
- It looks like your fix needs to be rolled out in a minor release since if 
only the client-side was rolled out, the server wouldn't read the new 
serialized format correctly. Is that correct?

I think it'd be good to update the description and subject to better capture 
the extent of the problem and when it might occur. I also think we should do a 
4.14 as soon as this gets reviewed by [~tdsilva] and committed.

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

Reply via email to