[
https://issues.apache.org/jira/browse/ACCUMULO-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13531530#comment-13531530
]
Hudson commented on ACCUMULO-769:
---------------------------------
Integrated in Accumulo-Trunk #578 (See
[https://builds.apache.org/job/Accumulo-Trunk/578/])
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/KeyRangePartitioner.java
*
/accumulo/trunk/core/src/main/java/org/apache/accumulo/core/client/mapreduce/lib/partition/RangePartitioner.java
*
/accumulo/trunk/core/src/test/java/org/apache/accumulo/core/client/mapreduce/lib/partition/RangePartitionerTest.java
> MapReduce API should not use Configuration to set Job state at submission
> time (ambiguous semantics)
> ----------------------------------------------------------------------------------------------------
>
> Key: ACCUMULO-769
> URL: https://issues.apache.org/jira/browse/ACCUMULO-769
> 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: http://www.atlassian.com/software/jira
