[
https://issues.apache.org/jira/browse/LUCENE-6819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adrien Grand updated LUCENE-6819:
---------------------------------
Attachment: LUCENE-6819.patch
I think it is a fair requirement to make the upgrade easier. Here is a patch
that removes index-time boosts. It makes Solr ignore index-time boosts, and log
a debug message when a value that is different from 1.0 is supplied, in order
to not break hard for users who would go to 7.0 without making sure to never
set boosts. I can change it to a hard exception if you would like it better.
As far as 6.x is concerned, I think it would be enough to deprecate
{{IndexableField.boost()}}, {{Field.setBoost(float)}} and methods in the Solr
client API that take a boost parameter (most of them already have a variant
that does not take a boost and implicitly sets it to 1.0, which we would keep)?
> Deprecate index-time boosts?
> ----------------------------
>
> Key: LUCENE-6819
> URL: https://issues.apache.org/jira/browse/LUCENE-6819
> Project: Lucene - Core
> Issue Type: Task
> Reporter: Adrien Grand
> Priority: Minor
> Attachments: LUCENE-6819.patch, LUCENE-6819-wip.patch
>
>
> Follow-up of this comment:
> https://issues.apache.org/jira/browse/LUCENE-6818?focusedCommentId=14934801&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14934801
> Index-time boosts are a very expert feature whose behaviour is tight to the
> Similarity impl. Additionally users have often be confused by the poor
> precision due to the fact that we encode values on a single byte. But now we
> have doc values that allow you to encode any values the way you want with as
> much precision as you need so maybe we should deprecate index-time boosts and
> recommend to encode index-time scoring factors into doc values fields instead.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
