[
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: [email protected]
For additional commands, e-mail: [email protected]
