[
https://issues.apache.org/jira/browse/ACCUMULO-1732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13779071#comment-13779071
]
Keith Turner commented on ACCUMULO-1732:
----------------------------------------
Unpredictable is probably a better work to use than surprising to describe what
I was thinking in my previous comment. We want to define behaviors that lead
to users being able to predict what will happen.
I misunderstood your first question.
bq. should we also make it available for other applications?
You are basically asking if we should make the table id available through the
client API. Possibly. I think we can make map reduce jobs behave in a
predictable way w/o doing this. For the more general point of make the table
id a first class citizen in the API, what are the use cases? Probably other
systems like M/R that access Accumulo in a distributed manner.
> 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
