[ https://issues.apache.org/jira/browse/HBASE-10602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13981790#comment-13981790 ]
Sergey Shelukhin commented on HBASE-10602: ------------------------------------------ some feedback on R > Cleanup HTable public interface > ------------------------------- > > Key: HBASE-10602 > URL: https://issues.apache.org/jira/browse/HBASE-10602 > Project: HBase > Issue Type: Improvement > Components: Client, Usability > Reporter: Nick Dimiduk > Assignee: Enis Soztutar > Priority: Blocker > Fix For: 0.99.0 > > Attachments: hbase-10602_v1.patch > > > HBASE-6580 replaced the preferred means of HTableInterface acquisition to the > HConnection#getTable factory methods. HBASE-9117 removes the HConnection > cache, placing the burden of responsible connection cleanup on whomever > acquires it. > The remaining HTable constructors use a Connection instance and manage their > own HConnection on the callers behalf. This is convenient but also a > surprising source of poor performance for anyone accustomed to the previous > connection caching behavior. I propose deprecating those remaining > constructors for 0.98/0.96 and removing them for 1.0. > While I'm at it, I suggest we pursue some API hygiene in general and convert > HTable into an interface. I'm sure there are method overloads for accepting > String/byte[]/TableName where just TableName is sufficient. Can that be done > for 1.0 as well? -- This message was sent by Atlassian JIRA (v6.2#6252)