[
https://issues.apache.org/jira/browse/SOLR-515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12583436#action_12583436
]
Erik Hatcher commented on SOLR-515:
-----------------------------------
bq. 1) it would be nice to make this use one of the existing PluginLoader APIs
(MapPluginLoader/MapInitializedPlugin or
NamedListPluginLoader/NamedListInitializedPlugin since we've been talking about
trying to standardize on them ... i don't think we have any types of Plugin's
at the moment that use SolrParams.
I looked at the plugin stuff, but it seemed that it wasn't appropriate for a
single implementation like this, but rather something like response writers
that have multiple implementations that can be picked up dynamically. 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? Or am I missing something?
> 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.
