[
https://issues.apache.org/jira/browse/PHOENIX-4382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16297892#comment-16297892
]
Vincent Poon commented on PHOENIX-4382:
---------------------------------------
[~jamestaylor] to answer your questions
- I don't think it matters what the prior or following fields are. For any
variable length field in an immutable table, you should see the problem
- In the old scheme, we don't write the separator byte for fixed length
columns. And for variable length, we only write the separator byte when the
column is null
- The space optimization works by serializing the separator byte, along with
the count of the # of nulls. So for a single null, it'd be something like [0,1]
- Correct, the server would have to be upgraded before the client.
I'll try to update the description/summary to provide more clarity. We can
also update the documentation on the phoenix website on the Storage Formats
page, to provide a warning about which values would be incorrect in the older
versions.
> 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)
