[ 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)