In a multi-tenant environment, I wouldn't want someone to change the storageHandler my tables are using. If we were to give storageHandler aliases it would be better if the alias was tied to the storageHandler. Though I'm not sure what advantages that would give apart from seeing something shorter in the DDL.
-Francis On 1/27/12 9:59 AM, "Enis Söztutar" <[email protected]> wrote: >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 >>
