[
https://issues.apache.org/jira/browse/HIVE-26984?focusedWorklogId=842596&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-842596
]
ASF GitHub Bot logged work on HIVE-26984:
-----------------------------------------
Author: ASF GitHub Bot
Created on: 31/Jan/23 14:14
Start Date: 31/Jan/23 14:14
Worklog Time Spent: 10m
Work Description: abstractdog commented on code in PR #3983:
URL: https://github.com/apache/hive/pull/3983#discussion_r1091974491
##########
common/src/java/org/apache/hadoop/hive/conf/HiveConf.java:
##########
@@ -6322,29 +6322,67 @@ public ZooKeeperHiveHelper getZKConfig() {
.trustStorePassword(trustStorePassword).build();
}
+ public static HiveConf create() {
+ return new HiveConf();
+ }
+
+ public static HiveConf create(Class<?> cls) {
+ return new HiveConf(cls);
+ }
+
+ public static HiveConf create(Configuration other, Class<?> cls) {
+ return new HiveConf(other, cls);
+ }
+
+
+ public static HiveConf create(HiveConf other) {
+ return new HiveConf(other);
+ }
+
+ /**
+ * Instantiating HiveConf is deprecated. Please use
+ * HiveConf#create() to construct a Configuration,
+ * this method will become private eventually.
Review Comment:
yeah, I was thinking about the same, and just for curiosity's sake: if
nothing is broken with private (or protected) constructors, can we make the
public -> private/protected step in this PR?
Issue Time Tracking
-------------------
Worklog Id: (was: 842596)
Time Spent: 1h 10m (was: 1h)
> Deprecate public HiveConf constructors
> --------------------------------------
>
> Key: HIVE-26984
> URL: https://issues.apache.org/jira/browse/HIVE-26984
> Project: Hive
> Issue Type: Improvement
> Reporter: László Bodor
> Assignee: László Bodor
> Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> From time to time we investigate configuration object problems that are hard
> to investigate. We can improve this area, e.g. with HIVE-26985, but first, we
> need to introduce a public static factory method to hook into the creation
> process. I can see this pattern in another projects as well, like:
> HBaseConfiguration.
> Creating custom HiveConf subclasses can be useful because putting optional
> (say: if else branches or whatever) stuff into the original HiveConf object's
> hot codepaths can turn it less performant instantly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
