HIVE-29046: Avoid unecessary perf overhead from handling deprecated properties in MetastoreConf #5897
+15
−57
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…roperties in MetastoreConf Looping through ~400 ConfVars enumeration entries on every creation of a new Configuration entry is resource wasteful and unecessary. The deprecated properties are static and known at compile time so there is no reason to search and register them on every creation of a new Configuration instance. In addition, the presence of deprecation information inside the ConfVars enumeration leads to boilerplate code that is not really necessary. 1. Move deprecated property registation in the existing static block 2. Drop constructors and variables related to deprecated keys in ConfVars 3. Drop DEPRECATED_TEST_ENTRY that is only useful for testing purposes and adapt existing tests
|
deniskuzZ
reviewed
Jun 25, 2025
| @@ -128,6 +128,13 @@ public class MetastoreConf { | |||
| keyToVars.put(var.varname, var); | |||
| keyToVars.put(var.hiveName, var); | |||
| } | |||
| Configuration.addDeprecations(new Configuration.DeprecationDelta[] { | |||
There was a problem hiding this comment.
can we just drop them in Hive-4.1?
There was a problem hiding this comment.
We don't have a policy in place about when and how to remove deprecated props so its our call. Personally, my goal here is to avoid the unnecessary perf hit so I don't mind removing them completely if you prefer this path.
Most often, when projects follow semantic versioning breaking changes only happen during major version bumps so ideally the removal should happen in 5.x. In Hive, we are not so dogmatic about it so I think we can afford such small breaking changes even in minor version bumps.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What changes were proposed in this pull request?
Why are the changes needed?
Improve performance & code maintenance.
Looping through ~400 ConfVars enumeration entries on every creation of a new Configuration entry is resource wasteful and unecessary. The deprecated properties are static and known at compile time so there is no reason to search and register them on every creation of a new Configuration instance. In addition, the presence of deprecation information inside the ConfVars enumeration leads to boilerplate code that is not really necessary.
Does this PR introduce any user-facing change?
No
How was this patch tested?
Existing tests