[
https://issues.apache.org/jira/browse/SOLR-515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12583465#action_12583465
]
Hoss Man commented on SOLR-515:
-------------------------------
bq. I looked at the plugin stuff, but it seemed that it wasn't appropriate for
a single implementation like this
Hmmm... I may be misremembering what the Loaders currently provide. Either
way: I'd prefer that new types of plugins implement one of the
*InitializedPlugin interfaces for uniformity moving forward.
bq. Wouldn't going with the plugin architecture make your proposed
SimilarityFactory unnecessary? You could have a similarity registered as
default, one as "writer", and one as "search". Right?
I'm not suggesting just having 2 Similarities per SolrCore, i'm suggesting that
a SimilarityFactory be asked to provide a Similarity to use each time a new
IndexWriter or a new SolrIndexSearcher is constructed. if the factory wants to
use maintain and use 1 or 2 Similarity instances for everything it can, or each
call to getSearchSimilarity could compute some stats on every field in the
index and return a new custom instance based on the data.
> 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, similarity_factory.patch,
> 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.
