[
https://issues.apache.org/jira/browse/HADOOP-6105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12732420#action_12732420
]
rahul k singh commented on HADOOP-6105:
---------------------------------------
The first comment defines the initial proposal , Which says that when both new
and old values are set in configuration we give preference
to new values. This we felt is not correct , we should give preference to old
value.As we are trying to be backward compatible here.
So in configuration if have both deprecated key and new key , new key's values
would be replaced by the deprecated key's values.
Now in taking the above consideration in mind we have 2 ways of solving this.
1.Try to maintain a single set of key value always .When we have both
deprecated key and new key , only maintain new key .So when we are trying to
read the Configuration xmls , if we encounter any deprecated key , we simply
replace new key's value with the deprecated key's value.
when we do "set" in configuration for the depercated keys, we simply set the
new key's with the values passed . When we do "get" we simply return the new
key mapping.
2. Always give preference to the deprecated key . While set of new values check
if deprecated keys are present , if yes , then simply set deprecated values.
We would like to go ahead with option 1. Where we make sure that old is
preferred at the start while loading the configuration , after that it
is simply the whichever key is set recently.
> Provide a way to automatically handle backward compatibility of deprecated
> keys
> -------------------------------------------------------------------------------
>
> Key: HADOOP-6105
> URL: https://issues.apache.org/jira/browse/HADOOP-6105
> Project: Hadoop Common
> Issue Type: Improvement
> Components: conf
> Reporter: Hemanth Yamijala
>
> There are cases when we have had to deprecate configuration keys. Use cases
> include, changing the names of variables to better match intent, splitting a
> single parameter into two - for maps, reduces etc.
> In such cases, we typically provide a backwards compatible option for the old
> keys. The handling of such cases might typically be common enough to actually
> add support for it in a generic fashion in the Configuration class. Some
> initial discussion around this started in HADOOP-5919, but since the project
> split happened in between we decided to open this issue to fix it in common.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
