[
https://issues.apache.org/jira/browse/HADOOP-6105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12723992#action_12723992
]
Hemanth Yamijala commented on HADOOP-6105:
------------------------------------------
There are atleast two issues that were discussed about this approach in
HADOOP-5919:
- With project split, how would we add deprecated keys from mapreduce or hdfs
into common.
- What if there's no one-to-one mapping from old keys to new keys.
With the project split over now, maybe the first issue requires a solution as
part of this JIRA. Owen's suggestion was to define a key like
hadoop.conf.extra.classes which would be a list of class names that will be
loaded by Configuration when it is loaded. By default this could be null, but
in a cluster installation, we could put up basic classes like JobConf. This
would give an opportunity for the extra classes to add more mappings to the new
keys.
The second problem is a bit more involved, though some obvious solutions exist.
And we could take the approach that we will not solve it in this patch, but
only restrict the utility of this framework for the more straightforward
mapping cases.
Thoughts ?
> 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.
