[
https://issues.apache.org/jira/browse/ACCUMULO-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13777585#comment-13777585
]
William Slacum commented on ACCUMULO-391:
-----------------------------------------
I've been a proponent of what Keith is talking about for a while. There's
nothing tying us to the current method of configuring jrrbs besides convention
(which I'm all for throwing out if the only reason for doing is "everyone else
is doing it"). The current {{Configurator}} mechanism we have now is a mess and
there are constraints dumped into the {{Configuration}} (such as the
only-setting-connection-info-once constraint we have) that user has to jump
through at least one hoop to even check. I think this discussion is best suited
to another ticket.
To get back on topic, I wouldn't worry about having things configured for
tables that aren't going to be scanned. It'd be nice to warn about it, but it's
not a show stopper. It's extra state that goes unevaluated, so really it's just
trimming the fat. I can't see a bug happening from it that wouldn't be caught
with minimal exercise/testing.
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
