hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "rahul k singh (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HADOOP-6105) Provide a way to automatically handle backward compatibility of deprecated keys
Date Fri, 17 Jul 2009 10:39:14 GMT

    [ 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) ,

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.

View raw message