[
https://issues.apache.org/jira/browse/ACCUMULO-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13788739#comment-13788739
]
Corey J. Nolet edited comment on ACCUMULO-391 at 10/8/13 12:36 AM:
-------------------------------------------------------------------
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.
All that being said- you have a good point about just implementing a new class
and I think that was William's position when he wrote the initial patch. It
looked like the majority of people on this thread were for just incorporating
the patch into the InputFormatBase but this can be changed if that's the
overall consensus.
was (Author: sonixbp):
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)
