accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Josh Elser (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-2493) BinaryFormatter needs to be refactored
Date Fri, 04 Dec 2015 03:00:16 GMT


Josh Elser commented on ACCUMULO-2493:

bq. Since adding an int maxLength option to Formatter.initialize would cause this issue to
be brought up again whenever someone wants another configuration option down the road, I was
thinking of changing Formatter.intialize to accept a hadoop Configuration object and let Formatters
configure themselves.

Good thinking. Convention-wise, we tend to make our own configuration objects instead of leveraging
Hadoop Configuration objects. Examples include {{BatchWriterConfig}}, {{ClientConfiguration}},
{{ConditionalWriterConfig}}. I'd tend to go that route just for some consistency with the
rest of the public API (assuming Formatters will eventually get pushed into the public API).

> BinaryFormatter needs to be refactored
> --------------------------------------
>                 Key: ACCUMULO-2493
>                 URL:
>             Project: Accumulo
>          Issue Type: Bug
>          Components: client
>            Reporter: Mike Drob
>            Assignee: Matt Dailey
>              Labels: newbie
>             Fix For: 1.7.1, 1.8.0
> BinaryFormatter is currently used in a couple places in the shell, but the code is hard
to read and understand. There is a static getlength, which is actually a setter, and all the
instance calls end up going through unnecessary static methods.
> This combination makes it hard to reuse BinaryFormatter objects, or even use multiple,
since the static state is likely to conflict.

This message was sent by Atlassian JIRA

View raw message