hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hemanth Yamijala (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HADOOP-6105) Provide a way to automatically handle backward compatibility of deprecated keys
Date Thu, 25 Jun 2009 10:03:07 GMT

    [ 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.


Mime
View raw message