phoenix-issues mailing list archives

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

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

chenglei commented on PHOENIX-5307:
-----------------------------------

[~lhofhansl], [~dbwong], I uploaded my patch, could you help me have a review´╝č thanks.

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