You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Upayavira (JIRA)" <ji...@apache.org> on 2016/07/18 22:16:21 UTC

[jira] [Commented] (LUCENE-6590) Explore different ways to apply boosts

    [ 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
 * &amp; 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org