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


Mime
View raw message