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 > VersioningIterator. > > 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 config. > > Thoughts? > > P.S. > 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 > http://gravatar.com/ctubbsii
