[
https://issues.apache.org/jira/browse/PHOENIX-5307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
chenglei updated PHOENIX-5307:
------------------------------
Description:
I noticed {{HashJoinMoreIT.testBug2961}} always failed after PHOENIX-5262,
which is different from this JIRA:
{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 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.
was:
I noticed {{HashJoinMoreIT.testBug2961}} always failed after PHOENIX-5262,
which is different from this JIRA:
{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 last field is variable length and also DESC,
when the last field is variable length and also {{DESC}}, the trailiing 0xFF is
not removed, so for such case, we should not set
{{lastInclusiveUpperSingleKey}} back to false.
> 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 this JIRA:
> {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 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)
