[
https://issues.apache.org/jira/browse/MAHOUT-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12876675#action_12876675
]
Drew Farris commented on MAHOUT-404:
------------------------------------
{quote}
Do I understand correctly that...
* Just about everything works as before, we just need to build options with
buildOption()
* Call addInputOption() and addOutputOption() to parse standard
input/output option
* Call getInputPath() and getOutputPath() to correctly determine input path?
{quote}
Yep, these are all correct. One subtlety that's different from before is that
the map returned by parseArgs(String[]) will contain keys with null values for
options without arguments, such as those used to indicate that an overwrite
should happen. I think that's the only added behavior.
{quote}
Should we not make the input/output options always present and parsed for all
jobs by moving to parseArgs()? like some other args are.
{quote}
There were some jobs that used arguments different from the standard -i and -o
options so I decided to leave these up to the developer implementing the job
(e.g: MatricMultiplicationJob which has two separate inputs) instead of
automatically adding them for all jobs.
Unrelated put worth pointing out to others who might come across this issue:
I'm assuming that not all jobs will use prepareJob in AbstractJob to set
themselves up. In cases like these it is pretty essential to pass the
Configuration objects into whichever job is being set up, otherwise they won't
be configured based on the options provided via GenericOptionsParser.
> AbstractJob improvements.
> -------------------------
>
> Key: MAHOUT-404
> URL: https://issues.apache.org/jira/browse/MAHOUT-404
> Project: Mahout
> Issue Type: Improvement
> Components: Utils
> Affects Versions: 0.4
> Reporter: Drew Farris
> Attachments: MAHOUT-404.patch, MAHOUT-404.patch, MAHOUT-404.patch
>
>
> Per discussion :
> http://lucene.472066.n3.nabble.com/Re-input-now-Dmapred-input-dir-td852297.html#a852297
> With the advent of the parsedArgs map returned by AbstractJob.parseArguments
> is there
> a need to pass Option arguments around anymore? Could AbstractJob maintain
> Options state in a sense?
> For example, from RecommenderJob:
> {code}
> Option numReccomendationsOpt =
> AbstractJob.buildOption("numRecommendations", "n",
> "Number of recommendations per user", "10");
> Option usersFileOpt = AbstractJob.buildOption("usersFile", "u",
> "File of users to recommend for", null);
> Option booleanDataOpt = AbstractJob.buildOption("booleanData", "b",
> "Treat input as without pref values", Boolean.FALSE.toString());
> Map<String,String> parsedArgs = AbstractJob.parseArguments(
> args, numReccomendationsOpt, usersFileOpt, booleanDataOpt);
> if (parsedArgs == null) {
> return -1;
> }
> {code}
> Could be changed to something like:
> {code}
> buildOption("numRecommendations", "n", "Number of recommendations per user",
> "10");
> buildOption("usersFile", "u", "File of users to recommend for", null);
> buildOption("booleanData", "b", "Treat input as without pref values",
> Boolean.FALSE.toString());
> Map<String,String> parsedArgs = parseArguments();
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
