: All tokenstreams and tokenfilters will of course have backwards : compatibility across minor releases at least, but these factories give : us some additional flexibility in how we preserve that backwards : compatibility for Solr. : : For example in a major release we might remove a deprecated : TokenStream alltogether, but by having the factories also, we can keep : continuity for Solr schemas (just change the implementation).
right -- otherthings the factories have given us in the past is the ability to add "optional" args to the factory declarations, that (when absent) default to the legacy behavior, but in all example configs we "suggest" a setting that provides "better" behavior -- since these are factory settings, they can even change hte underlying Tokenizer/TOkenFilter that is produced by the factory. FWIW: the other thing you may not be aware of is that schema.xml has always had a "version" attribute on the top level <schema/> declaration that also dictates some default behavior. For example: initially all solr fields were multiValued by default, but if you have version="1.1" (or higher) then the "default" value for the multiValued property of fields changes. it's one more peice of flexability that the factories have when deciding what tokenizer/filter to produce in the goal of backcompatibility (but sensible defaults) -Hoss --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
