On 1/27/12 12:18 PM, "Enis Söztutar" <[email protected]> wrote:
>On Fri, Jan 27, 2012 at 10:31 AM, Francis Liu <[email protected]> wrote: > >> 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. >> > >This is exactly what I am proposing. a shortname or alias for the handler, >which is a simple name => class mapping like hbase => >org.apache.hcatalog.hbase.HBaseHCatStorageHandler. What I meant when I said "alias was tied to the storageHandler" is that the alias is defined by the storageHandler and is not configurable. > > >> Though I'm not sure what advantages that would give apart from seeing >> something shorter in the DDL. >> > >I think the biggest advantage is that, the storage handler for a specific >store is pluggable. >In the sense that, you can create the table in hive declaring that the >storage handler is 'hbase', >but when accessing through hcat, the table definition will work, since >hcat >will override the storage >handler with it's own impelementation. This sounds like trouble. StorageHandler implementations should not change depending on wether it is via Hive or HCat. That is one of the reasons we are doing HCATALOG-237 so we can reuse the same one on both platforms. Also, hive and hcat's hbase StorageHandler are not meant to be compatible with each other. I am ok with having an alias but making it configurable or changing just adds more complexity than it's worth IMHO. > >In a multi tenant case, if you want to make sure nobody can override the >storage handler class, you can still just declare >the name of the handler class in the store descriptor as it is today. > >Enis > > >> >> -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 >> >> >> >> >>
