lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doron Cohen (JIRA)" <>
Subject [jira] [Commented] (LUCENE-2986) divorce defaultsimilarityprovider from defaultsimilarity
Date Thu, 24 Mar 2011 06:10:06 GMT


Doron Cohen commented on LUCENE-2986:

+1 for this change (I did not remember discussing this, but other than remembering I am consistent

Patch looks very clean.

Minor technical comments - concerning just some tests:

- some of the DSP implementations are still named xyzSimilarity - I think it would be more
clear to name them xyzSimilarityProvider:
-- o.a.solr.schema.MockConfigurableSimilarity
-- o.a.l.index.TestIndexWriterConfig.MySimilarity
-- o.a.l.index.TestIndexReaderCloneNorms.SimilarityOne
-- o.a.l.index.TestNorms.SimilarityOne
-- o.a.l.index.TestOmitTf.SimpleSimilarity

- for few of the above it is not only the name - they are still doing both roles: {code}extends
DefaultSimilarity implements SimilarityProvider{code}:
-- o.a.l.index.TestOmitTf.SimpleSimilarity

Other than that I think it is good to go in.

Also, tests from trunk/lucene and trunk/solr passed.
(I am seeing problems in running all trunk tests, at least on Windows, but I'll send a separate
mail to the list on that)

> divorce defaultsimilarityprovider from defaultsimilarity
> --------------------------------------------------------
>                 Key: LUCENE-2986
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Task
>            Reporter: Robert Muir
>            Assignee: Robert Muir
>            Priority: Minor
>             Fix For: 4.0
>         Attachments: LUCENE-2986.patch
> In LUCENE-2236 as a start, we made DefaultSimilarity which implements the factory interface
(SimilarityProvider), and also extends Similarity.
> Its factory interface just returns itself always by default.
> Doron mentioned it would be cleaner to split the two, and I thought it would be good
to revisit it later.
> Today as I was looking at SOLR-2338, it became pretty clear that we should do this, it
makes things a lot cleaner. I think currently its confusing to users to see the two apis mixed
if they are trying to subclass.

This message is automatically generated by JIRA.
For more information on JIRA, see:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message