[
https://issues.apache.org/jira/browse/ACCUMULO-1732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13779041#comment-13779041
]
Keith Turner commented on ACCUMULO-1732:
----------------------------------------
bq. The same issue applies to renames in general for any arbitrary application
that scans tables.
Alot of the client side code already resolves a table id early and uses the
table id. But I am not sure this happens everywhere.
bq. 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?
I think this system should be designed such that when its working correctly it
does not behave in surprising ways. I do not think we should design the system
to have surprising behavior that can be leveraged when the system is working
incorrectly.
> 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
