Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Date: Tue, 2 Sep 2014 18:26:21 +0000 (UTC)
From: "Carter (JIRA)" <jira@apache.org>
To: dev@hbase.apache.org
Message-ID: <JIRA.12738486.1409682331000.10864.1409682381080@Atlassian.JIRA>
In-Reply-To: <JIRA.12738486.1409682331000@Atlassian.JIRA>
References: <JIRA.12738486.1409682331000@Atlassian.JIRA>
 <JIRA.12738486.1409682331741@arcas>
Subject: [jira] [Created] (HBASE-11879) Change TableInputFormatBase to take
 interface arguments
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Carter created HBASE-11879:
------------------------------

             Summary: Change TableInputFormatBase to take interface arguments
                 Key: HBASE-11879
                 URL: https://issues.apache.org/jira/browse/HBASE-11879
             Project: HBase
          Issue Type: Improvement
            Reporter: Carter
            Assignee: Carter


As part of the ongoing interface abstraction work, I'm now investigating {{TableInputFormatBase}}, which has two methods that break encapsulation:

{code}
protected HTable getHTable();
protected void setHTable(HTable table);
{code}

While these are protected methods, the base @InterfaceAudience.Public is abstract, meaning that it supports extension by user code.

I propose deprecating these two methods and replacing them with these four, once the Table interface is merged:

{code}
protected Table getTable();
protected void setTable(Table table);
protected RegionLocator getRegionLocator();
protected void setRegionLocator(RegionLocator regionLocator);
{code}

Since users will frequently call {{setTable}} and {{setRegionLocator}} together, it probably also makes sense to add the following convenience method:

{code}
protected void setTableAndRegionLocator(Table table, RegionLocator regionLocator);
{code}


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)