+1. Let's clean it up before 1.0. Including a clean HTableInterface. The tricky part of HTableInterface was what to include in it. Up to this point the guiding principle was to expose nothing of the internal implementation (i.e. nothing about regions or start/end keys, etc).
Thanks for stepping in and finish the job that I should have finished, Nick! -- Lars ________________________________ From: Nick Dimiduk <[email protected]> To: hbase-dev <[email protected]> Sent: Monday, February 24, 2014 3:03 PM Subject: Cleanup HTable public interface 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. Can that be done for 1.0 as well?
