[ 
https://issues.apache.org/jira/browse/HIVE-17167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16105613#comment-16105613
 ] 

Alan Gates commented on HIVE-17167:
-----------------------------------

Sort of, but not quite like that.  The constructor to MetastoreConf is private 
so that an instance of this object can never be instantiated.  The intent is to 
use Configuration instead, since this allows passing in a HiveConf and it will 
"just work".  So doing:
{code}
Configuration conf = MetastoreConf.newMetastoreConf();
MetastoreConf.setVar(conf, ConfVars.X, "val");
{code}
will work and avoid the issue you are concerned about.

The loophole is that a user could do:
{code}
Configuration conf = MetastoreConf.newMetastoreConf();
conf.set("metastore.myconfig.name", "x");
conf.set("hive.metastore.myconfig.name", "y");
{code}

So the rule is, as long as the users use the MetastoreConf methods, all is 
good.  If not, things can go sideways on them.  For clients this should be ok 
as they should only be interacting with the config by calling the setMetaConf 
methods in IMetaStoreClient, which will do the right thing.  For hook writers 
and Hive developers, they will have to be aware of this subtlety if they want 
to set metastore configuration variables.  That is unfortunate.

If MetastoreConf subclasses Configuration (as HiveConf does) then it will not 
be able to operate on a HiveConf object as is.  It would have to construct a 
new instance of Configuration from HiveConf, which is expensive.  It seems to 
me better to optimize for interoperability.

> Create metastore specific configuration tool
> --------------------------------------------
>
>                 Key: HIVE-17167
>                 URL: https://issues.apache.org/jira/browse/HIVE-17167
>             Project: Hive
>          Issue Type: Sub-task
>          Components: Metastore
>            Reporter: Alan Gates
>            Assignee: Alan Gates
>         Attachments: HIVE-17167.patch
>
>
> As part of making the metastore a separately releasable module we need 
> configuration tools that are specific to that module.  It cannot use or 
> extend HiveConf as that is in hive common.  But it must take a HiveConf 
> object and be able to operate on it.
> The best way to achieve this is using Hadoop's Configuration object (which 
> HiveConf extends) together with enums and static methods.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to