accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Corey J. Nolet (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (ACCUMULO-391) Multi-table Accumulo input format
Date Tue, 08 Oct 2013 00:38:42 GMT

    [ 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)

Mime
View raw message