[ 
https://issues.apache.org/jira/browse/PHOENIX-5839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Istvan Toth updated PHOENIX-5839:
---------------------------------
    Description: 
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.

  was:
As noticed by [~gjacoby] , the semantics of the
CompatUtil#setStopRow method are incorrect for HBase 1.3

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.


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

Reply via email to