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:42: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
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
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 case, we should not set {{lastInclusiveUpperSingleKey}} back to false.



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

Mime
View raw message