[
https://issues.apache.org/jira/browse/SOLR-515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12583391#action_12583391
]
Hoss Man commented on SOLR-515:
-------------------------------
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.
2) existing IndexSchema.init code will throuw ClassCast immediatly if someone
attempts to use a class that isn't really a Similarity (because it attempts
cast right away) ... reading your patch, i think this error will be defered
until first use -- which might be a red herring for people, better to test it
ASAP.
3) i was going to suggest skipping the factory and going with something like...
{code}
abstract class SolrSimilarity implements Similarity {
abstract void init(NamedList);
}
{code}
...but then it occurred to me that with a factory pattern we can give custom
Similarities the opportunity to precompute stats about the index before their
use...
{code}
public abstract class SimilarityFactory {
// init code here
/** Get an uninformed Similarity instance */
public abstract Similarity getSimilarity();
/** Get a Similiarity instance for use by an IndexWriter updating a known
IndexSchema */
public Similarity getWriterSimilarity(IndexSchema schema) { return
getSimilarity(); }
/** Get a Similiarity instance for use by an SolrIndexSearcher */
public Similarity getSearchSimilarity(SolrIndexSearcher searcher) { return
getSimilarity(); }
}
{code}
...with IndexSchema.getSimilarity() being deprecated, but still functional by
calling factory.getSimilarity()
An API like that, and a lot more interesting similarity implementations become
possible.
> 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.
