mschoch
commented
2 years ago NOTE: while investigating these issues, I have found a limitation in the way we allow for custom scoring. Due to the API design, when using custom scorers, it is not possible for them know (and therefore use) a user specified boost. At this time it's not clear if this belongs internal to the scoring, or if perhaps all boosting should be external to scoring. This PR does not attempt to address this realization at all, rather it focuses on improving behavior with the existing API limitations.
While investigating the behavior of several queries using the query boost capability a few issues were found.
First, an optimization in the boolean query, would replace the boolean searcher with internal "should" searcher, in the case where it was the only one (no "must" or "must not"). This optimization is valid, but as implemented today, it looses track of the users boost. As this seems to be a minor optimization, it is temporarily disabled to allow for correct boosting behavior.
Second, the boolean searcher, which by default will use a composite scorer (sum constituent scores), was ignoring the user requested boost value. A new boosting variant of the composite scorer is introduced. This variant first sums the scores, then multiplies by the boost.
Third, the numeric range searcher was defaulting to a constant score of 1.0, and it too ignored the requested boost value. The code has been updated to return a constant score equal to the boost (1.0 * boost).