On Fri, Jan 11, 2013 at 12:39 PM, Christopher <[EMAIL PROTECTED]> wrote:
> Would it make sense to require IteratorSettings to validate options by
> passing the options to the class when they are set? This could be useful
> for fast failure on things like: invalid number of versions set on the
> However, right now, IteratorSettings does not assume we have the class we
> are configuring available on the classpath at the moment it is constructed.
> It currently has a constructor that accepts fully-qualified class names as
> an argument, and carries it as a string throughout its lifecycle. To get
> fast failure, we'd have to get rid of that, and only allow Iterators to be
> specified by their Class, and then we could instantiate the class and call
> "validateOption(key, value)" or something similar.
I do not like making the client have the class they are trying to
configure for a server on their classpath. There is a thrift method
that client can call on any tablet server to see if the server has a
particular class. This model could be extended to support checking
> On a related note- I was thinking that we're starting to develop this
> pattern of carrying configuration in objects for different component
> classes (Iterators via IteratorSettings, BatchWriters via
> BatchWriterConfig, etc.), and then we have per-table and
> tserver/master/gc/etc.-specific configuration). It seems like we should
> start thinking about more generic ways of doing this, that's still useful
> to the respective APIs (I'd hate to pass around Properties objects, or a
> Map<String,String> to everything).
I agree. Configuring an accumulo client outside of java code can be
cumbersome. It would be nice if I could pass some sort of config file
to the Connector that would configure all of the knobs on the client.
Open a ticket for 1.6
> Christopher L Tubbs II