Yes, I believe we can make it so that this works for storage handlers other than hbase. Plus, we can keep the current functionality of loading storage handlers by classname.
Enis On Fri, Jan 27, 2012 at 8:50 AM, Sushanth Sowmyan <[email protected]>wrote: > I like this idea - it definitely makes it way more readable. > > So the idea is, then, is to make it generic so it'd work for more > storage handlers than hbase - would it be possible to look for conf of > the sort of hive.storage.handler.[storagehandlername].class given that > storage handler name in the create statement? > > If so, then this gets a definite +1 from me. > > -Sushanth > > > On Thu, Jan 26, 2012 at 7:05 PM, Enis Söztutar <[email protected]> wrote: > > Hi Hcat devs, > > > > While working on the hbase storage handler, I noticed that although the > > storage handlers are pluggable as it is, the user has to explicitly write > > down the class name instead of just the name of the store, like 'hbase'. > So > > I am proposing to introduce named storage handlers, with pluggable > naming. > > So instead of: > > > > CREATE TABLE test1(foo int, bar int) > > STORED BY 'org.apache.hcatalog.hbase.HBaseHCatStorageHandler' > > > > The table can be created by: > > > > CREATE TABLE test1(foo int, bar int) > > STORED BY 'hbase' > > > > And the name -> class mapping is read from the configuration with smt > like: > > <property> > > <name>hive.storage.handler.hbase.class</name> > > <value>org.apache.hcatalog.hbase.HBaseHCatStorageHandler</value> > > </property> > > > > Something like this will also allow HCat to override hbase handler with > > it's current implementation without the need to change the table > > definition. What do you guys think, if it is something to pursue, I can > > move the discussion to a hive jira. > > > > Thanks, > > Enis >
