[
https://issues.apache.org/jira/browse/PHOENIX-4382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16300904#comment-16300904
]
Hadoop QA commented on PHOENIX-4382:
------------------------------------
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12903332/PHOENIX-4382.v3.master.patch
against master branch at commit 412329a7415302831954891285d291055328c28b.
ATTACHMENT ID: 12903332
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 3 new
or modified tests.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:red}-1 release audit{color}. The applied patch generated 1 release
audit warnings (more than the master's current 0 warnings).
{color:red}-1 lineLengths{color}. The patch introduces the following lines
longer than 100:
+ table.getImmutableStorageScheme() ==
ImmutableStorageScheme.SINGLE_CELL_ARRAY_WITH_OFFSETS
+ private <T extends Number> void testValues(boolean immutable, PDataType<?>
dataType, List<T> testData) throws Exception {
+ public SingleCellColumnExpression(PColumn column, String displayName,
QualifierEncodingScheme encodingScheme, ImmutableStorageScheme
immutableStorageScheme) {
+ }, dataColRef.getFamily(), dataColRef.getQualifier(),
encodingScheme, immutableStorageScheme);
+ KeyValueColumnExpression kvExp = scheme !=
PTable.ImmutableStorageScheme.ONE_CELL_PER_COLUMN ? new
SingleCellColumnExpression(scheme)
+ return new PArrayDataTypeEncoder(byteStream, oStream,
numElements, type, SortOrder.ASC, false, getSerializationVersion());
+ // array serialization format where bytes are immutable (does not support
prepend/append or sorting)
+ if (serializationVersion == IMMUTABLE_SERIALIZATION_VERSION ||
serializationVersion == IMMUTABLE_SERIALIZATION_V2) {
+ if (isNullValue(arrayIndex, bytes, initPos,
serializationVersion, useShort, indexOffset, currOffset, elementLength)) {
+ int separatorBytes = serializationVersion ==
PArrayDataType.SORTABLE_SERIALIZATION_VERSION ? 3 : 0;
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/1685//testReport/
Release audit warnings:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/1685//artifact/patchprocess/patchReleaseAuditWarnings.txt
Console output:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/1685//console
This message is automatically generated.
> 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)
