[
https://issues.apache.org/jira/browse/ACCUMULO-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13781223#comment-13781223
]
ASF subversion and git services commented on ACCUMULO-391:
----------------------------------------------------------
Commit d340d82c08d4b2181d6900cea1455913f268ba6e in branch
refs/heads/ACCUMULO-391 from [~sonixbp]
[ https://git-wip-us.apache.org/repos/asf?p=accumulo.git;h=d340d82 ]
The legacy mapred InputFormatBase now verifies (and fixes the scanner for) a
possible change in table name that could happen between the configuration of
the map/reduce job and the actual processing of the scanner for a specific
split. In that case, the most recent table name associated with the id is
always used for the scanner (though the table name that was expected during job
setup is still used in the RangeInputSplit). ACCUMULO-391
> Multi-table Accumulo input format
> ---------------------------------
>
> Key: ACCUMULO-391
> URL: https://issues.apache.org/jira/browse/ACCUMULO-391
> Project: Accumulo
> Issue Type: New Feature
> Reporter: John Vines
> Assignee: Corey J. Nolet
> Priority: Minor
> Labels: mapreduce,
> Fix For: 1.6.0
>
> Attachments: ACCUMULO-391.patch, multi-table-if.patch,
> new-multitable-if.patch
>
>
> Just realized we had no MR input method which supports multiple Tables for an
> input format. I would see it making the table the mapper's key and making the
> Key/Value a tuple, or alternatively have the Table/Key be the key tuple and
> stick with Values being the value.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
