accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: AccumuloInputFormat getters
Date Thu, 17 Jul 2014 01:59:55 GMT
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.elser@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.elser@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
>>>>
>>>>
>>>

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