phoenix-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lars Hofhansl (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (PHOENIX-5307) Fix HashJoinMoreIT.testBug2961 failing after PHOENIX-5262
Date Fri, 31 May 2019 21:29:00 GMT

    [ https://issues.apache.org/jira/browse/PHOENIX-5307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16853434#comment-16853434
] 

Lars Hofhansl commented on PHOENIX-5307:
----------------------------------------

Good find. Looks good to me.

HashJoinMoreIT passes now.

+1

 

> 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)

Mime
View raw message