[
https://issues.apache.org/jira/browse/HIVE-15780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15927606#comment-15927606
]
anishek commented on HIVE-15780:
--------------------------------
something linked along similar lines of thinking as above is reported in
HIVE-16220
> HiveConf evaluation and management
> ----------------------------------
>
> Key: HIVE-15780
> URL: https://issues.apache.org/jira/browse/HIVE-15780
> Project: Hive
> Issue Type: Improvement
> Components: HiveServer2
> Reporter: anishek
> Assignee: anishek
>
> This is a placeholder Jira to see if HiveConf class can be rewired to give
> better performance and security.
> * most of the variables in hive can be changed by the user, there are few
> variables that are part of the "hive.conf.restricted.list" configuration,
> with recent additions via HIVE-15713. Extending the list to include more
> admin / cluster wide variables should be included.
> * By default any new variable that is created is available for end user to
> change, given this is a huge list and a lot them are cluster wide
> configurations, it would be better that any instance of variables in hiveconf
> should be part of system / restricted list with additional parameter during
> object instance creation to include if user can change it.
> * since this class extends hadoop Configuration class any _get*_ method
> called on instance of HiveConf is evaluated for variable substitution etc,
> this is not required except for few variables like
> "hive.downloaded.resources.dir", hence the class could just have a map of
> most of the properties which should help in faster configuration lookup.
> * for every session we create a new instance of hiveconf, if we can segregate
> the conf's into system level / user level etc then have some sort of
> composite pattern to represent hive conf such that a single instance of
> system configuration is used across sessions.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
