[
https://issues.apache.org/jira/browse/HADOOP-6105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12732453#action_12732453
]
rahul k singh commented on HADOOP-6105:
---------------------------------------
To make the above proposals more clear:
for example:
==========
A (a deprecated key)
B(new key mapping for A) ,
SA (setValueForA) ,
SB(setValueForB) ,
GA(get("A))
GB(get("B")).
1. Always maintain new keys only. At the time of loading configuration xml , if
A and B are present , we simply , replace B's values with A's value.
* Advantages with this approach:
** The whole system is consistent. we always maintain the single set of values
, hence whole behavior is deterministic w.r.t SA or SB which ever is called
latest.
* Disadvantage:
** Deprecated values would be over written. so if we call SB then A's values
are also changed. //Is this a issue??
2.Always give preference to deprecated keys. If we have both A and B present in
configuration , give preference to A always.
* Advantage:
** System is deterministic as we always get deprecated value if present.
* Disadvantage:
** GB would check if GA is available and if yes , would return the A's
values.So if user calls SB , and then calls GB , they would expect B's values,
instead they would get A's value
Any comments ?
> 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.
