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 <ctubb...@apache.org> 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 <josh.el...@gmail.com> 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 <josh.el...@gmail.com> > >>> 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 > >>>> > >>>> > >>> >
