I currently use a custom similarity, but it changes so infrequently that we took the simple route of hardcoding the special field logic into the similarity.
FWIW: the topic of adding more configuration options to the <similarity/> config has come up in the past -- using reflection to detect if the class specified implemented "SolrSimilarity" and if so call an init(NamedList) method on it -- but one of the reasons that never happened is because of the same questions you raise: in an ideal world you would put a lot of configuration in the <similarity/> section, you'd put it in the field/fieldType sections .... but what would that look like? would you express what you wnated the lengthNorm function to be for each field using groovy script? would the Similarity class define some functions and then ask the FieldType to specify whatthe variables of that function should be? It's really hard to design general solutions to these types of questions without some solid use cases. : class aware of the schema. One straightforward way to do this would be : to have it implement SolrCoreAware, even though this is currently : disallowed by the list of 'aware compatible' classes in SolrResourceLoader. The "aware compatible" list exists to ensure that we have a predictable and reliable method and order for initializing plugins, so people don't try to go crazy with cross dependencies that we can't satisfy. it may in fact make sense to allow Similarity to be SolrCoreAware ... i'd have to think about it some more though. : Are there going to be any obvious problems with this? The only one I can : think of would be if the IndexSchema and therefore the Similarity are : shared across multiple cores. Nothing gets shared across cores -- there is (i think) going to be the notion of a shared classloader for plugins where you want true singletons regardless of the number of cores, but you wouldn't have to worry about that unless you implement your plugin as a singleton *and* you load it using that special shared lib directory. -Hoss
