That could work. It also lines up with the idea of having "one expected
return class" for certain methods.
Maybe have some pojo or interface to keep us honest would make the API
aspect easier to manage?
On 7/16/14, 10:09 PM, William Slacum wrote:
It's dubious to say it's "internals", when it gets hamjammed into a map of
strings to other strings that's going to be passed around to many processes.
Maybe we can make our own serializable pojo that implements some interface
for consumers to use. That would at least let us hide internals and have a
single entry point into the Hadoop configuration.
On Wed, Jul 16, 2014 at 9:59 PM, Christopher <[email protected]> wrote:
Well, you can subclass to introspect. And, if you feel the API can be
improved by offering stronger getter/setter support with the stability
guarantees that we care about for public API, go ahead. (It probably
wouldn't change much anyway, since we now treat protected as public API,
too, I think). I won't object to the improvements... just explaining why
it's like that. My concern if you were to do this would be whether this
would actually add too much bloat or not to consumers of the API who don't
need to subclass, and the lack of 1-to-1 in many cases... but if you can
address those things sufficiently, I wouldn't object.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Wed, Jul 16, 2014 at 9:55 PM, Josh Elser <[email protected]> wrote:
Ultimately, I feel like there's a big problem when I, an "experienced
Accumulo developer", am getting frustrated with the API.
As it stands right now, I have no way to introspect the contents of a
Configuration to ensure that the state is as I expect it to be. I'm stuck
dumping the entire configuration, and grep'ing it to see if the values I
expect are in there with *some* key. If so, I then have to try to unravel
what exactly is the appropriate key that the value should be paired with.
I can understand the complexity in the storage of relevant data within
the
Configuration, but this seems unnecessarily complicated to me.
On 7/16/14, 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
http://gravatar.com/ctubbsii
On Wed, Jul 16, 2014 at 9:43 PM, Josh Elser <[email protected]>
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
