[
https://issues.apache.org/jira/browse/ACCUMULO-4195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15246434#comment-15246434
]
Shawn Walker commented on ACCUMULO-4195:
----------------------------------------
While it seems trivial, designing this going particularly well for me.
A naive solution just ends up with some {{FileOperationsOptions}} object which
holds all possible parameters for all {{FileOperations}} methods. While this
solves one problem (changes to {{FileOperations}} inputs no longer require
global code changes), it introduces another: it's no longer obvious which
methods support which parameter groups. e.g. "Why can't I specify a range when
opening a reader for seeking?" "What does the set of column families mean when
I'm opening a writer?" "How do I rate limit a {{getFileSize()}}?"
A separate {{...Options}} object for each of the 5 primary method types would
be possible, but would be a lot of boilerplate, and might prove difficult to
maintain.
My first attempt in code attempted to meet in the middle, and ended up enjoying
the worst of both designs.
> Generalized configuration object for Accumulo rfile interaction
> ---------------------------------------------------------------
>
> Key: ACCUMULO-4195
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4195
> Project: Accumulo
> Issue Type: Improvement
> Reporter: Josh Elser
> Assignee: Shawn Walker
> Fix For: 1.8.0
>
>
> Taken from https://github.com/apache/accumulo/pull/90/files#r59489073
> On [~ShawnWalker]'s PR for ACCUMULO-4187 which adds rate-limiting on major
> compactions, we noted that many of the changes were related to passing an
> extra argument (RateLimiter) around through all of the code which is related
> to file interaction.
> It would be nice to move to a centralized configuration object instead of
> having to add a new argument every time some new feature is added to the
> file-path.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
