[
https://issues.apache.org/jira/browse/PHOENIX-5839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17085143#comment-17085143
]
Hadoop QA commented on PHOENIX-5839:
------------------------------------
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/13000153/PHOENIX-5839.4.x.v1.patch
against 4.x branch at commit dec131d8a4de666c06dabc332383fd7e75c2d3aa.
ATTACHMENT ID: 13000153
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:red}-1 core tests{color}. The patch failed these unit tests:
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.DropTableWithViewsIT
Test results:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/3759//testReport/
Console output:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/3759//console
This message is automatically generated.
> CompatUtil#setStopRow semantics problem
> ---------------------------------------
>
> Key: PHOENIX-5839
> URL: https://issues.apache.org/jira/browse/PHOENIX-5839
> Project: Phoenix
> Issue Type: Bug
> Components: core
> Affects Versions: 4.x
> Reporter: Istvan Toth
> Assignee: Istvan Toth
> Priority: Major
> Attachments: PHOENIX-5839.4.x.v1.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> As noticed by [~gjacoby] , the semantics of the CompatUtil#setStopRow method
> are incorrect for HBase 1.3. Specifically, we invert the semantics of the
> *inclusive* flag.
> Due to the quirks of the HBase 1.3 scan semantics, the resulting behaviour in
> the specific cases where it used is correct (in fact this behaviour is needed
> for correct operation), but when used outside this specific use case (single
> row scan), it would cause problems.
> Find some other solution that solves the backwards compatibility problem, and
> does not invert the semantics of the call in the range (not single row) scan
> case.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
