hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Lawlor (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HBASE-13442) Rename scanner caching to a more semantically correct term such as row limit
Date Tue, 21 Apr 2015 20:50:59 GMT

     [ 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.

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

View raw message