[
https://issues.apache.org/jira/browse/LUCENE-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14640288#comment-14640288
]
Adrien Grand commented on LUCENE-6590:
--------------------------------------
bq. What do you think is possible in terms of updating 5.x to make the
transition easier?
My plan was to backport the change, make Query.clone/setBoost/getBoost
deprecated, change the default rewrite implementation to something like:
{code}
public Query rewrite(IndexReader reader) throws IOException {
if (boost != 1f) {
Query rewritten = clone();
rewritten.setBoost(1f);
rewritten = new BoostQuery(rewritten, boost);
return rewritten;
}
return this;
}
{code}
and then review our existing queries to make sure they always end up delegating
to super.rewrite (I know some of them, like DisjunctionMaxQuery, end up just
returning "this", so that would have to be fixed to return super.rewrite()
instead.)
I think that should work?
bq. Another thought... boosts really only make sense for boosting one clause
over another. so another approach that might be less invasive (and won't break
"instanceof" checks and current unwrapping code) is to just add boost to
BooleanClause.
That's an interesting idea but I think this only applies to DefaultSimilarity?
Other Similarities tend to handle boosts as multiplicative factors to the
scores (because they return 1 in queryNorm instead of
1/sqrt(sumOfSquaredWeights))? Also this might be an issue for
DisjunctionMaxQuery which could not have different boosts per sub query anymore?
bq. This might have some influence on weighting in the surround (span) queries,
but that can be fixed later if it is needed at all.
I'm curious what issues you are foreseeing? (I'm not very familiar with
surround queries...)
> 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
> Attachments: 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]
