accumulo-notifications mailing list archives

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


Corey J. Nolet commented on ACCUMULO-391:


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:
>             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

View raw message