[
https://issues.apache.org/jira/browse/ACCUMULO-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13788739#comment-13788739
]
Corey J. Nolet commented on ACCUMULO-391:
-----------------------------------------
Chris,
Thank you for your feedback! All of your bullet points look like quite simple
fixes and I can work to incorporate them. As for new class vs. old deprecated
class- It looked like a few people in this thread were for making the API
change in this release- the complexity introduced by keeping keeping separate
iterator, range, columns, and tablenames on the job just made it very prone to
falling into a bad state.
It seems like the only reason we'd need the single-table case to have its own
set of methods anymore is so that we can continue to support legacy code
without introducing breaking changes for users. I tried to limit the
maintenance for the deprecated methods by ultimately converting the single
table objects to TableQueryConfig objects when they are used by the internal
code.
> 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)
