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.
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
Keith Turner 2013-01-11, 17:58