[
https://issues.apache.org/jira/browse/SOLR-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erik Hatcher updated SOLR-515:
------------------------------
Attachment: (was: similarity_factory.patch)
> SimilarityFactory patch: facilitate parameterizable Similarity implementations
> ------------------------------------------------------------------------------
>
> Key: SOLR-515
> URL: https://issues.apache.org/jira/browse/SOLR-515
> Project: Solr
> Issue Type: New Feature
> Components: search
> Affects Versions: 1.3
> Reporter: Erik Hatcher
> Assignee: Erik Hatcher
> Fix For: 1.3
>
> Attachments: similarity_factory.patch
>
>
> Solr currently allows a pluggable Lucene Similarity to be specified as:
> <similarity class="org.apache.lucene.search.DefaultSimilarity"/>
> This patch does not change this syntax at all, but detects whether a
> Similarity or a SimilarityFactory is specified. The new SimilarityFactory
> class passes a NamedList from the config file into a getSimilarity(NamedList)
> method.
> Yes, I used an interface, damn it! Let the battles continue. I've spoken
> with my code on the issue. But sure, I'll acquiesce on the topic and turn it
> into an abstract class if I must - stupid programming languages!
> object-oriented programming, not interface or abstract oriented programming
> :) All I ask is ya show me a good case where this interface won't suit your
> needs, and I'll reply that instead of thinking the problem is the interface,
> consider it is how the interface is used - it's implicitly designed to be
> simply that, an interface. You want a different way to configure, don't like
> NamedLists for some reason maybe?, we change IndexSchema Similarity
> construction smarts, perhaps creating another interface. Same diff, sort of.
> I'm proud of the unit test, no XPath in sight.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
