You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@phoenix.apache.org by "Lars Hofhansl (JIRA)" <ji...@apache.org> on 2019/06/01 01:46:00 UTC
[jira] [Commented] (PHOENIX-5307) Fix HashJoinMoreIT.testBug2961
failing after PHOENIX-5262
[ https://issues.apache.org/jira/browse/PHOENIX-5307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16853535#comment-16853535 ]
Lars Hofhansl commented on PHOENIX-5307:
----------------------------------------
[~dbwong], [~tdsilva], [~vincentpoon], if I get another +1 I'll commit.
> Fix HashJoinMoreIT.testBug2961 failing after PHOENIX-5262
> ---------------------------------------------------------
>
> Key: PHOENIX-5307
> URL: https://issues.apache.org/jira/browse/PHOENIX-5307
> Project: Phoenix
> Issue Type: Bug
> Affects Versions: 4.15.0
> Reporter: chenglei
> Assignee: chenglei
> Priority: Major
> Attachments: PHOENIX-5307_v1-4.x-HBase-1.4.patch
>
>
> I noticed {{HashJoinMoreIT.testBug2961}} always failed after PHOENIX-5262, which is different from PHOENIX-5290:
> {code}
> java.lang.AssertionError
> at org.apache.phoenix.end2end.join.HashJoinMoreIT.testBug2961(HashJoinMoreIT.java:908)
> {code}
> I think this problem is caused by following line 453 modified in PHOENIX-5262:
> {code}
> 445 if ( !isFixedWidth && ( sepByte == QueryConstants.DESC_SEPARATOR_BYTE
> 446 || ( !exclusiveUpper
> 447 && (fieldIndex < schema.getMaxFields() || inclusiveUpper || exclusiveLower) ) ) ) {
> 448 key[offset++] = sepByte;
> 449 // Set lastInclusiveUpperSingleKey back to false if this is the last pk column
> 450 // as we don't want to increment the null byte in this case
> 451 // To test if this is the last pk column we need to consider the span of this slot
> 452 // and the field index to see if this slot considers the last column
> 453 lastInclusiveUpperSingleKey &= (fieldIndex + slotSpan[i]) < schema.getMaxFields()-1;
> 454 }
> {code}
> It did not consider the case that the last field is variable length and also DESC, when the last field is variable length and also {{DESC}}, the trailiing {{0xFF}} is not removed when stored in HBASE, so for such case, we should not set {{lastInclusiveUpperSingleKey}} back to false.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)