You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by Bryan Beaudreault <bb...@hubspot.com.INVALID> on 2022/09/09 15:18:54 UTC

[DISCUSS] Deprecate Scan.setCaching?

Hey team,

Is there a reason not to deprecate Scan.setCaching and Scan.getCaching?

Way back it was originally the primary way to control how much data is
returned per RPC. But it’s awkward for that purpose because rows can be
varying sizes. These days setMaxResultSize is a much better API for that
purpose.

Another reason to setCaching is for small scans where you just want N
results and you close the scanner after fetching those. But these days
setLimit is a better way to achieve that.

I can’t think of another reason why one would want to exclusively use
setCaching, but open to opinions.

Thoughts? I can file a jira and submit a patch if there is consensus.

Re: [DISCUSS] Deprecate Scan.setCaching?

Posted by "张铎(Duo Zhang)" <pa...@gmail.com>.
For me I would like to use setMaxResultSize and setLimit.

But I think setting the lines returned per request is still a valid requirement?

Bryan Beaudreault <bb...@hubspot.com.invalid> 于2022年9月9日周五 23:19写道:
>
> Hey team,
>
> Is there a reason not to deprecate Scan.setCaching and Scan.getCaching?
>
> Way back it was originally the primary way to control how much data is
> returned per RPC. But it’s awkward for that purpose because rows can be
> varying sizes. These days setMaxResultSize is a much better API for that
> purpose.
>
> Another reason to setCaching is for small scans where you just want N
> results and you close the scanner after fetching those. But these days
> setLimit is a better way to achieve that.
>
> I can’t think of another reason why one would want to exclusively use
> setCaching, but open to opinions.
>
> Thoughts? I can file a jira and submit a patch if there is consensus.