[
https://issues.apache.org/jira/browse/ACCUMULO-1741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790960#comment-13790960
]
Christopher Tubbs commented on ACCUMULO-1741:
---------------------------------------------
It has been discussed on ACCUMULO-391 that perhaps the multi-table InputFormat
needs to be a separate class, in which case, the existing API would remain
as-is, and internally delegate to the multi-table methods as a specialized case
(multi-table with number of tables = 1).
The advantage of this is to cater to the common use case (1 table, familiar
API), without creating churn. If the multi-table version's API proves its
worth, the single table version could be deprecated in its entirety, rather
than piecemeal. That would be less churn.
Additionally, given the desired stability of the M/R API, we'd probably want to
keep it around for awhile, even if it were deprecated (maybe even until a major
version change, like 2.0). Deprecating it in whole makes the lame duck
maintenance easier. But, it's not clear we want to deprecate it just yet. The
multi-table API hasn't been proven by real-world stress testing yet. I'd hate
to deprecate the familiar in favor of something that users find cumbersome and
inconvenient (I don't expect this, but I think we should buffer against it; as
we stabilize the API, and the project matures, this is going to be an
increasing concern).
> Clean up setters in the InputFormatBase API to take tables and properties all
> at once.
> --------------------------------------------------------------------------------------
>
> Key: ACCUMULO-1741
> URL: https://issues.apache.org/jira/browse/ACCUMULO-1741
> Project: Accumulo
> Issue Type: Sub-task
> Reporter: Corey J. Nolet
> Assignee: Corey J. Nolet
> Priority: Minor
> Fix For: 1.6.0
>
>
--
This message was sent by Atlassian JIRA
(v6.1#6144)
