phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "chenglei (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (PHOENIX-5307) Fix HashJoinMoreIT.testBug2961 failed after PHOENIX-5262
Date Thu, 30 May 2019 03:39:00 GMT

     [ 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, so for such
field, 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 field, we should not set lastInclusiveUpperSingleKey back to false.


> Fix HashJoinMoreIT.testBug2961 failed 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
>            Priority: Major
>
>  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 field, we should not set {{lastInclusiveUpperSingleKey}} back to false.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message