[
https://issues.apache.org/jira/browse/ACCUMULO-1732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13778978#comment-13778978
]
Christopher Tubbs commented on ACCUMULO-1732:
---------------------------------------------
The same issue applies to renames in general for any arbitrary application that
scans tables. If we make the M/R API robust against this, should we also make
it available for other applications? Or is the M/R API a special case (because
it's implementation details that it creates a separate scanner per mapper).
Also, maybe that's the behavior you want? Maybe you're trying to rename a table
and replace it with a backup clone, to limit the impact of some problematic or
corrupt data?
> Resolve table name to table id once in Accumulo input format
> ------------------------------------------------------------
>
> Key: ACCUMULO-1732
> URL: https://issues.apache.org/jira/browse/ACCUMULO-1732
> Project: Accumulo
> Issue Type: Bug
> Affects Versions: 1.4.0
> Reporter: Keith Turner
> Assignee: Corey J. Nolet
> Priority: Minor
>
> AccumuloInputFormat (and I suspect AccumuloOutputFormat) sends the table name
> to each mapper. The mapper uses this table name to create a scanner. In the
> case of the following events a map reduce job could read from two different
> table ids.
> # start M/R job reading table A
> # rename table A (tableId=1) to table C
> # rename table B (tableId=2) to table A
> If the input format passed table id 1 to the mappers, then the renames would
> not cause a problem.
--
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
