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

Niels Basjes updated HBASE-26762:
---------------------------------
    Description: 
Issue HBASE-25299 is about the Scan#setRowPrefixFilter having not the expected 
effects when using also the setStartRow and/or setStopRow.

The setRowPrefixFilter is intended to make setting the right startRow and 
stopRow for prefix scans. So it was always intended of using it *instead* of 
doing separate setStartRow and/or setStopRow calls.

The reason for adding this to the Scan (~ 8 years ago, HBASE-11990 ) was that 
calculating the correct start and stop row for doing the very efficient prefix 
scan is very very hard to do right in the generic case.

This is still a current usecase and many of my applications rely on this 
function (I even prefer the HBase Client when connecting to Google BigTable for 
this method).

With issue HBASE-25299 it has now been marked as deprecated.
Quote from the changes made in HBASE-25299:

{code}
@deprecated since 3.0.0. The scan result might be unexpected in some cases.
{code}
Yes, if you use this very valuable method incorrectly it will yield incorrect 
results.
I do not consider this a valid reason to deprecate it.

So I do agree with the confusion of the effects as described in HBASE-25299 
which should be fixed with additional documentation.

I disagree with the deprecation of this method.
 

I'll put up a pull request in which I improve the documentation and remove the 
deprecation.

  was:
Issue HBASE-25299 is about the Scan#setRowPrefixFilter having not the expected 
effects when using also the setStartRow and/or setStopRow.

The setRowPrefixFilter is intended to make setting the right startRow and 
stopRow for prefix scans. So it was always intended of using it *instead* of 
doing separate setStartRow and/or setStopRow calls.

The reason for adding this to the Scan (~ 8 years ago, HBASE-11990 ) was that 
calculating the correct start and stop row for doing the very efficient prefix 
scan is very very hard to do right in the generic case.

Many of my applications rely on this function and with issue HBASE-25299 it has 
now been marked as deprecated which I consider to be a very bad idea.

For me this method is also a good reason to use the HBase Client when 
connecting to Google BigTable.

 

So I do agree with the confusion of the effects as described in HBASE-25299 
which should be fixed with additional documentation.

I disagree with the deprecation of this method.

 

I'll put up a pull request in which I improve the documentation and remove the 
deprecation.


> Scan#setRowPrefixFilter incorrectly marked as deprecated
> --------------------------------------------------------
>
>                 Key: HBASE-26762
>                 URL: https://issues.apache.org/jira/browse/HBASE-26762
>             Project: HBase
>          Issue Type: Bug
>          Components: Client, scan
>    Affects Versions: 3.0.0-alpha-2
>            Reporter: Niels Basjes
>            Assignee: Niels Basjes
>            Priority: Major
>
> Issue HBASE-25299 is about the Scan#setRowPrefixFilter having not the 
> expected effects when using also the setStartRow and/or setStopRow.
> The setRowPrefixFilter is intended to make setting the right startRow and 
> stopRow for prefix scans. So it was always intended of using it *instead* of 
> doing separate setStartRow and/or setStopRow calls.
> The reason for adding this to the Scan (~ 8 years ago, HBASE-11990 ) was that 
> calculating the correct start and stop row for doing the very efficient 
> prefix scan is very very hard to do right in the generic case.
> This is still a current usecase and many of my applications rely on this 
> function (I even prefer the HBase Client when connecting to Google BigTable 
> for this method).
> With issue HBASE-25299 it has now been marked as deprecated.
> Quote from the changes made in HBASE-25299:
> {code}
> @deprecated since 3.0.0. The scan result might be unexpected in some cases.
> {code}
> Yes, if you use this very valuable method incorrectly it will yield incorrect 
> results.
> I do not consider this a valid reason to deprecate it.
> So I do agree with the confusion of the effects as described in HBASE-25299 
> which should be fixed with additional documentation.
> I disagree with the deprecation of this method.
>  
> I'll put up a pull request in which I improve the documentation and remove 
> the deprecation.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

Reply via email to