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. 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). -- Christopher L Tubbs II http://gravatar.com/ctubbsii
