[
https://issues.apache.org/jira/browse/HBASE-13541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14524406#comment-14524406
]
Dave Latham commented on HBASE-13541:
-------------------------------------
If having the rowLimit is useful, I think that one is reasonable. As far as
paging goes, I think most people doing batches of work don't actually care how
often the client is chunking data from the server. If they really do (for
example, serving some UI where they don't know how often the user will request
a new page), they can create a new Scanner for the new page each time which is
probably better not to hold the state open on the server anyway.
> Deprecate Scan caching in 2.0.0
> -------------------------------
>
> Key: HBASE-13541
> URL: https://issues.apache.org/jira/browse/HBASE-13541
> Project: HBase
> Issue Type: Sub-task
> Reporter: Jonathan Lawlor
> Attachments: HBASE-13541-WIP.patch
>
>
> The public Scan API exposes caching to the application. Caching deals with
> the number of rows that are transferred per scan RPC request issued to the
> server. It does not seem like a detail that users of a scan should control
> and introduces some unneeded complication. Seems more like a detail that
> should be controlled from the server based on the current scan request RPC
> load. This issue proposes that we deprecate the caching API in 2.0.0 so that
> it can be removed later. Of course, if there are any concerns please raise
> them here.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
