accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <>
Subject Re: AccumuloInputFormat getters
Date Thu, 17 Jul 2014 01:56:14 GMT
The problem is that our setters/getters were never 1-to-1. Some setters set
a group of related config, but the getters need to read them individually,
to perform different functions. For instance, setting the connector
information... you'd pass username and password information, but the code
inside (or a subclass) may need just the username, or the instanceName, or
(in the past) the default table name, etc. Or, for example, when we've
deprecated some setters in favor of others, the corresponding getters no
longer made sense. For instance, when we added the ability to specify a
password file, the entire concept of getting a password back wouldn't make
sense... you never gave a password in the first place. It's now no longer
just deserialization, but you'd have to add new functionality to read the
password file and return a password, that has nothing to do with needs
internal to the class... but would just be providing a complete
setter/getter API for the sake of doing it.

I'm not going to argue that a particular field is or isn't going to
change... I'm just explaining the history of why it's like that, and the
kinds of changes that have occurred in the past. Personally, I don't think
people should be depending on our serialization. They launched the job,
they should know what they put in it. If they need to pass state to
different components of their code, they shouldn't depend on our
serialization to carry that state, even if it seems like there's some

Christopher L Tubbs II

On Wed, Jul 16, 2014 at 9:48 PM, Josh Elser <> wrote:

> The value of the name of the table that the AccumuloInputFormat is going
> to read is subject to change? Isn't the point of a getter that it can
> unwrap the specifics of the serialization within the configuration and
> present the high-level constructs (username, AuthenticationToken, table
> name, IteratorSettings, etc) that users expect?
> On 7/16/14, 9:46 PM, Christopher wrote:
>> Because those things represent internals of the configuration that are
>> subject to change, and we don't want end users becoming dependent on them.
>> They are protected, because they may be needed for subclassing, where the
>> subclass assumes some greater risk than an end user of the API.
>> --
>> Christopher L Tubbs II
>> On Wed, Jul 16, 2014 at 9:43 PM, Josh Elser <> wrote:
>>  Why are all of the getters on the AccumuloInputFormat protected (really,
>>> InputFormatBase) instead of public?
>>> This has repeatedly infuriated me as it makes it impossible for me to
>>> verify that the Configuration actually has the data in it as needed.
>>> It seems intentional so I figured I would ask before making a ticket and
>>> changing it.
>>> - Josh

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message