accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-4195) Generalized configuration object for Accumulo rfile interaction
Date Mon, 25 Apr 2016 16:47:13 GMT


ASF GitHub Bot commented on ACCUMULO-4195:

Github user joshelser commented on a diff in the pull request:
    --- Diff: core/src/test/java/org/apache/accumulo/core/client/mock/
    @@ -225,7 +225,8 @@ private ImportTestFilesAndData prepareTestFiles() throws Throwable
         fs.delete(tempFile, true);
    -    FileSKVWriter writer = FileOperations.getInstance().openWriter(tempFile.toString(),
fs, defaultConf, null, AccumuloConfiguration.getDefaultConfiguration());
    +    FileSKVWriter writer = FileOperations.getInstance().openWriter().ofFile(tempFile.toString(),
fs, defaultConf)
    --- End diff --
    The "verbage" here feels a little strange to me (maybe because you tried to preserve the
original `openWriter()` methods?). What do you think about something like:
    FileOperations.getInstance().newWriterBuilder().ofFile(tempFile.toString(), fs, defaultConf)
    Using the common "builder" and "build" terminology makes it a bit obvious how this works.
"openWriter" would imply to me that something is being opened (that I would need to close)
and I'm not sure what "execute" would be doing at all on some I/O handle.
    I know this is a little nit-picky, but if we're going to make the APIs better, I'd be
in favor of making them as clear as possible to prevent ourselves from coming back here soon.

> Generalized configuration object for Accumulo rfile interaction
> ---------------------------------------------------------------
>                 Key: ACCUMULO-4195
>                 URL:
>             Project: Accumulo
>          Issue Type: Improvement
>            Reporter: Josh Elser
>            Assignee: Shawn Walker
>             Fix For: 1.8.0
> Taken from
> 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

View raw message