[
https://issues.apache.org/jira/browse/HBASE-13442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Lawlor updated HBASE-13442:
------------------------------------
Attachment: HBASE-13442-proposal.diff
Here's a look at what the proposed API change would look like (before it is
integrated into the rest of the codebase). In summary:
* The current APIs setCaching/getCaching are deprecated in 2.0.0
* The new APIs setRPCRowLimit/getRPCRowLimit take the place of caching
* There is no change in the actual behavior behavior (yet... see below), just a
change in name. The name change makes it clear what using the API will actually
do.
Discussion:
* Thoughts on new API names? Other recommendations?
* Should behavior stay the same? Alternatively, as [~davelatham] suggested,
should we instead make it actually limit the number of rows the client returns
to the app (once the row limit is reached the scanner would be closed and
return null on future calls to scanner.next())? If the alternative is pursued,
it would be more appropriate to call it rowLimit rather than rpcRowLimit.
* Anything other suggestions?
> Rename scanner caching to a more semantically correct term such as row limit
> ----------------------------------------------------------------------------
>
> Key: HBASE-13442
> URL: https://issues.apache.org/jira/browse/HBASE-13442
> Project: HBase
> Issue Type: Sub-task
> Reporter: Jonathan Lawlor
> Attachments: HBASE-13442-proposal.diff
>
>
> Caching acts more as a row limit now. By default in branch-1+, a Scan is
> configured with (caching=Integer.MAX_VALUE, maxResultSize=2MB) so that we
> service scans on the basis of buffer size rather than number of rows. As a
> result, caching should now only be configured in instances where the user
> knows that they will only need X rows. Thus, caching should be renamed to
> something that is more semantically correct such as rowLimit.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
