accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hudson (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-769) MapReduce API should not use Configuration to set Job state at submission time (ambiguous semantics)
Date Thu, 13 Dec 2012 21:26:12 GMT


Hudson commented on ACCUMULO-769:

Integrated in Accumulo-Trunk #578 (See [])
    ACCUMULO-769 Updated partitioners to reflect the only valid, mutable JobContext, which
is simply Job; This change is API-compatible with current code that isn't broken, because
Job is a JobContext, so no deprecation is needed (though code that uses this may need to be
recompiled). (Revision 1421521)

     Result = SUCCESS
ctubbsii : 
Files : 
* /accumulo/trunk/core/src/main/java/org/apache/accumulo/core/client/mapreduce/lib/partition/
* /accumulo/trunk/core/src/main/java/org/apache/accumulo/core/client/mapreduce/lib/partition/
* /accumulo/trunk/core/src/test/java/org/apache/accumulo/core/client/mapreduce/lib/partition/

> MapReduce API should not use Configuration to set Job state at submission time (ambiguous
> ----------------------------------------------------------------------------------------------------
>                 Key: ACCUMULO-769
>                 URL:
>             Project: Accumulo
>          Issue Type: Bug
>          Components: client
>    Affects Versions: 1.4.1, 1.4.0
>            Reporter: Christopher Tubbs
>            Assignee: Christopher Tubbs
>            Priority: Minor
>             Fix For: 1.5.0
> ACCUMULO-267 made this change, but I think it was the wrong way to go about it.
> From the comments on ACCUMULO-267:
> This is the wrong way to go about doing this fix. The reason why it took a JobContext
is so that it could accept a "Job" object. This was modeled after the pattern Hadoop was using
for FileOutputFormat, which is somewhat the standard for conventions in configuring MR jobs.
> While JobContext does specifically state that's what it's purpose is, it is a base class,
and Job extends JobContext, and includes a comment that describes it as holding the state
of the job at submission time. This API should really be taking a "Job" object, rather than
a "JobContext" object. Further, because Job is the only JobContext that actually works as
intended here, the change from JobContext to Job does not require any deprecation, because
Job will still work, and any other JobContext that isn't a Job will still fail. (We would
have to deprecate the ones that were added in 1.4 that took a Configuration object, though...
because those were never "correct", if we are going off of the conventions set by Hadoop's
provided OutputFormats).
> It is somewhat annoying to deprecate something in 1.5 that was added in 1.4... especially
since it allows people to go back to what they were doing before. But, I think it might be
worth it to be consistent with the established conventions, and to clarify the semantics of
the methods (we are, after all, modifying the state of a job we are about to submit, and not
just an arbitrary configuration, which is used for all sorts of things).

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message