lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <>
Subject [jira] [Commented] (LUCENE-6590) Explore different ways to apply boosts
Date Mon, 08 Feb 2016 22:36:40 GMT


ASF subversion and git services commented on LUCENE-6590:

Commit 340dc9ca5039244b2a78e284dd707e4466b3f3d4 in lucene-solr's branch refs/heads/branch_5_4
from [~andyetitmoves]
[;h=340dc9c ]

SOLR-8418: Adapt to changes in LUCENE-6590 for use of boosts with MLTHandler and Simple/CloudMLTQParser

git-svn-id: 13f79535-47bb-0310-9956-ffa450edef68

> Explore different ways to apply boosts
> --------------------------------------
>                 Key: LUCENE-6590
>                 URL:
>             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

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

View raw message