Currently, FieldType throws a RuntimeException if there are any
"extra" properties in the configuration. I think SchemaField does
something similar.
I'd like to consider not doing this. My main case is I want to be
able to store semantic information about the FieldType with the
FieldType. Doing this now, requires creating a whole separate object
model that overlays the FieldType and stores the information elsewhere
(i.e. DB). For example, say you want to denote what language a given
field type supports, one has to store this information elsewhere, when
it could easily be seen as a property of the FieldType. I think right
now, people often rely on naming conventions to convey this, such as
text_zh or text_it or something like that and that doesn't extend very
well, IMO. These new attributes would allow applications to make use
of richer semantics for FieldType w/o harming Solr in anyway (I think.)
From the looks of it, FieldType has all the functionality already
built in, minus a few lines where the exception is thrown if there are
"extra" attributes.
I think a similar argument can be made for SchemaField as well (and
probably other things like RequestHandler, etc. but "baby steps" first)
Any thoughts/objections?
-Grant
