Use the Weight#matches mode for highlighting by default #96068
Conversation
This PR adapts the unified highlighter to use the Weight#matches API by default when possible. This is the default mode in Lucene for some time now. For cases where the matches API won't work (nested and parent-child queries), the matches mode is disabled automatically. I didn't expose an option to explicitly disable this mode because that should be seen as an internal implementation detail. With this change, matches that span multiple terms are highlighted together (something that users asked for years) and the clauses that don't match the document are ignored.
jimczi
added
>enhancement
:Search Relevance/Highlighting
|
Pinging @elastic/es-search (Team:Search) |
...arent-join/src/internalClusterTest/java/org/elasticsearch/join/query/ChildQuerySearchIT.java
Outdated
Show resolved
Hide resolved
server/src/main/java/org/elasticsearch/lucene/search/uhighlight/CustomUnifiedHighlighter.java
Outdated
Show resolved
Hide resolved
That would be my preference yep, happy to discuss (and adapt) if we think it should be considered differently. |
|
@romseygeek I disabled the Matches mode if a runtime field is queried or if |
|
@romseygeek, as discussed I added an undocumented index setting to disable the weight matches. |
server/src/main/java/org/elasticsearch/lucene/search/uhighlight/CustomUnifiedHighlighter.java
Show resolved
Hide resolved
server/src/main/java/org/elasticsearch/search/fetch/subphase/highlight/DefaultHighlighter.java
Outdated
Show resolved
Hide resolved
jimczi
changed the title
Fix bwc tests broken by elastic#96068
Fix bwc tests broken by elastic#96068
|
@jimczi I know the likelihood is low but is there any chance we can get this ER backported to 8.4? I have a customer who runs a multi-tenant cluster and cannot perform the upgrade to 8.10 in the near term and they have an escalated customer situation on their end. I've set expectations that the chance of a backport is low but since you mentioned it as a possibility in an earlier comment just wanted to follow up. |
Unfortunately not since 8.4.x is not released anymore. |
|
@jimczi thanks for the quick response! |
…asticsearch version In elasticsearch 8.10.2 and higher versions highligh behaviour is different more info here: elastic/elasticsearch#96068 https://liferay.atlassian.net/browse/LPD-2141
…asticsearch version In elasticsearch 8.10.2 and higher versions highligh behaviour is different more info here: elastic/elasticsearch#96068 https://liferay.atlassian.net/browse/LPD-2141
…asticsearch version In elasticsearch 8.10.2 and higher versions highligh behaviour is different more info here: elastic/elasticsearch#96068 https://liferay.atlassian.net/browse/LPD-2141
…asticsearch version In elasticsearch 8.10.2 and higher versions highligh behaviour is different more info here: elastic/elasticsearch#96068 https://liferay.atlassian.net/browse/LPD-2141
…asticsearch version In elasticsearch 8.10.2 and higher versions highligh behaviour is different more info here: elastic/elasticsearch#96068 https://liferay.atlassian.net/browse/LPD-2141
…asticsearch version In elasticsearch 8.10.2 and higher versions highligh behaviour is different more info here: elastic/elasticsearch#96068 https://liferay.atlassian.net/browse/LPD-2141
This PR adapts the unified highlighter to use the Weight#matches mode by default when possible. This is the default mode in Lucene for some time now. For cases where the matches mode won't work (nested and parent-child queries),
the matches mode is disabled automatically.
I didn't expose an option to explicitly disable this mode because that should be seen as an internal implementation detail. With this change, matches that span multiple terms are highlighted together (something that users asked for years) and the clauses that don't match the document are ignored.
Note that this new mode is enabled only when
require_field_matchis true and the query doesn't contain:Closes #29561