[ https://issues.apache.org/jira/browse/LUCENE-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15383180#comment-15383180 ]
Upayavira commented on LUCENE-6590: ----------------------------------- I upgraded my Solr configs to match the 5.5, and the issue was still there. I eventually tracked down this snippet in Solr's SchemaSimilarityFactory.java: {{ * <p> * <b>NOTE:</b> Users should be aware that even when this factory uses a single default * <code>Similarity</code> for some or all fields in a Query, the behavior can be inconsistent * with the behavior of explicitly configuring that same <code>Similarity</code> globally, because * of differences in how some multi-field / multi-clause behavior is defined in * <code>PerFieldSimilarityWrapper</code>. In particular please consider carefully the documentation * & implementation of {@link Similarity#coord} and {@link Similarity#queryNorm} in * {@link ClassicSimilarity} compared to {@link PerFieldSimilarityWrapper} * </p> }} which suggests that adding a SchemaSimilarityFactory will *change* the scoring, even if you continue to use the ClassicSimilarityFactory. > Explore different ways to apply boosts > -------------------------------------- > > Key: LUCENE-6590 > URL: https://issues.apache.org/jira/browse/LUCENE-6590 > Project: Lucene - Core > Issue Type: Wish > Reporter: Adrien Grand > Priority: Minor > Fix For: 5.4 > > Attachments: LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch, > LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch > > > Follow-up from LUCENE-6570: the fact that all queries are mutable in order to > allow for applying a boost raises issues since it makes queries bad cache > keys since their hashcode can change anytime. We could just document that > queries should never be modified after they have gone through IndexSearcher > but it would be even better if the API made queries impossible to mutate at > all. > I think there are two main options: > - either replace "void setBoost(boost)" with something like "Query > withBoost(boost)" which would return a clone that has a different boost > - or move boost handling outside of Query, for instance we could have a > (immutable) query impl that would be dedicated to applying boosts, that > queries that need to change boosts at rewrite time (such as BooleanQuery) > would use as a wrapper. > The latter idea is from Robert and I like it a lot given how often I either > introduced or found a bug which was due to the boost parameter being ignored. > Maybe there are other options, but I think this is worth exploring. -- This message was sent by Atlassian JIRA (v6.3.4#6332) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org