Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Tue, 21 Apr 2015 20:50:59 +0000 (UTC)
From: "Jonathan Lawlor (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12819806.1428609323000.66641.1429649459778@Atlassian.JIRA>
In-Reply-To: <JIRA.12819806.1428609323000@Atlassian.JIRA>
References: <JIRA.12819806.1428609323000@Atlassian.JIRA>
 <JIRA.12819806.1428609323089@arcas>
Subject: [jira] [Updated] (HBASE-13442) Rename scanner caching to a more
 semantically correct term such as row limit
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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