BlendedTermQuery's equals method should not disregard boosts #48184
Assignees
Labels
>enhancement
:Search/Search
Search-related issues that do not fall into other categories
v7.6.0
v8.0.0-alpha1
Comments
cbuescher
added
>enhancement
:Search/Search
|
Pinging @elastic/es-search (:Search/Search) |
cbuescher
pushed a commit
to cbuescher/elasticsearch
that referenced
this issue
Oct 17, 2019
This changes the queries equals() method so that the boost factors for each term are considered for the equality calculation. This means queries are only equal if both their terms and associated boosts match. The ordering of the terms doesn't matter as before, which is why we internally need to sort the terms and boost for comparison on the first equals() call like before. Boosts that are `null` are considered equal to boosts of 1.0f because topLevelQuery() will only wrap into BoostQuery if boost is not null and different from 1f. Closes elastic#48184
cbuescher
pushed a commit
that referenced
this issue
Oct 25, 2019
This changes the queries equals() method so that the boost factors for each term are considered for the equality calculation. This means queries are only equal if both their terms and associated boosts match. The ordering of the terms doesn't matter as before, which is why we internally need to sort the terms and boost for comparison on the first equals() call like before. Boosts that are `null` are considered equal to boosts of 1.0f because topLevelQuery() will only wrap into BoostQuery if boost is not null and different from 1f. Closes #48184
cbuescher
pushed a commit
that referenced
this issue
Oct 25, 2019
This changes the queries equals() method so that the boost factors for each term are considered for the equality calculation. This means queries are only equal if both their terms and associated boosts match. The ordering of the terms doesn't matter as before, which is why we internally need to sort the terms and boost for comparison on the first equals() call like before. Boosts that are `null` are considered equal to boosts of 1.0f because topLevelQuery() will only wrap into BoostQuery if boost is not null and different from 1f. Closes #48184
cbuescher
pushed a commit
that referenced
this issue
Oct 25, 2019
This changes the queries equals() method so that the boost factors for each term are considered for the equality calculation. This means queries are only equal if both their terms and associated boosts match. The ordering of the terms doesn't matter as before, which is why we internally need to sort the terms and boost for comparison on the first equals() call like before. Boosts that are `null` are considered equal to boosts of 1.0f because topLevelQuery() will only wrap into BoostQuery if boost is not null and different from 1f. Closes #48184
This was referenced Feb 3, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently the BlendedTermQuerys
equals()method only checks equality of the terms it contains, not of the boosts associated to them.This is an unexpected behaviour and a little suprising e.g. when using equality checks in tests.
The text was updated successfully, but these errors were encountered: