[
https://issues.apache.org/jira/browse/SOLR-2338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13012802#comment-13012802
]
Hoss Man commented on SOLR-2338:
--------------------------------
bq. but if you think its not confusing, we could support the global
<similarity/>, which would always be used unless you supply a different
<similarity/> for a specific field.
i don't personally think it would be confusing, but i also don't think we need
to advertise it in the example.
we should definitely encourage using similarity per field type, but for people
who have used it in the past, having it continue to work as a "global default"
when fieldTypes don't define a similarity gives us nice back-compatibility.
More generally though, i'm thinking that the same {{<similarity/>}} tag can be
used for both the old style (global default) Similarity/SimilarityFactory and
the new SimilarityProviderFactory using instanceof checks...
* instanceOf SimilarityProviderFactory
** instantiate it and use it.
* instanceOf SimilarityFactory
** instantiate and wrap it in a SolrSimilarityProvider that delegates to it
when the field type has no similarity set on it. return an anonymous
SimilarityProviderFactory that uses this SolrSimilarityProvider
* instanceOf Similarity
** instantiate and wrap it in a SolrSimilarityProvider that delegates to it
when the field type has no similarity set on it. return an anonymous
SimilarityProviderFactory that uses this SolrSimilarityProvider
...that way there is only one "global" option that can be specified, and we
don't have to deal with weird edge cases of what the default should be for a
fieldTYpe w/o a similarity if the schema.xml specifies both {{<similarity/>}}
and {{<similarityProvider/>}}
The one other thing i just noticed is that you have
SimilarityProviderFactory.init(SolrParams) ... my vote would be to start using
NamedList based initialization for all new types of solr plugins. it requires
more verbosity in the config, but it supports a lot more types of information
(multivalued keys, nested lists/maps, etc...) and could eventually lead us to
actually being able to validate our config files using an XMLSchema and/or DTD
(since the element/node names are finite)
> improved per-field similarity integration into schema.xml
> ---------------------------------------------------------
>
> Key: SOLR-2338
> URL: https://issues.apache.org/jira/browse/SOLR-2338
> Project: Solr
> Issue Type: Improvement
> Components: Schema and Analysis
> Affects Versions: 4.0
> Reporter: Robert Muir
> Assignee: Robert Muir
> Attachments: SOLR-2338.patch, SOLR-2338.patch
>
>
> Currently since LUCENE-2236, we can enable Similarity per-field, but in
> schema.xml there is only a 'global' factory
> for the SimilarityProvider.
> In my opinion this is too low-level because to customize Similarity on a
> per-field basis, you have to set your own
> CustomSimilarityProvider with <similarity class=.../> and manage the
> per-field mapping yourself in java code.
> Instead I think it would be better if you just specify the Similarity in the
> FieldType, like after <analyzer>.
> As far as the example, one idea from LUCENE-1360 was to make a "short_text"
> or "metadata_text" used by the
> various metadata fields in the example that has better norm quantization for
> its shortness...
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
