-
Notifications
You must be signed in to change notification settings - Fork 24.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Highlighting should leverage the new field retrieval API #59931
Comments
Pinging @elastic/es-search (:Search/Highlighting) |
Highlighting already work for multi-fields and aliases so the switch would only be helpful to retrieve the content of copied fields (the source of the |
I really like that this change would reduce the need for stored fields -- users sometimes set |
HighlighterUtils.loadFieldValues() loads values directly from the source, and then callers have to deal with filtering out values that would have been removed by an ignore_above filter on keyword fields. Instead, we can use the ValueFetcher for the relevant field, which handles all this logic for us. Closes #59931.
HighlighterUtils.loadFieldValues() loads values directly from the source, and then callers have to deal with filtering out values that would have been removed by an ignore_above filter on keyword fields. Instead, we can use the ValueFetcher for the relevant field, which handles all this logic for us. Closes elastic#59931.
…5441) HighlighterUtils.loadFieldValues() loads values directly from the source, and then callers have to deal with filtering out values that would have been removed by an ignore_above filter on keyword fields. Instead, we can use the ValueFetcher for the relevant field, which handles all this logic for us. Closes #59931.
In #55363 we're adding a core functionality to retrieve field content from the mappings. Today highlighting is limited to fields that are contained in the
_source
or stored explicitly. Switching to the new API would allow to highlight alias, copy_to and multi-fields seamlessly without requiring the targeted field to be included in the_source
. As such, this issue can be seen as a follow up of #55363, for internal usage we should use this generic API since it provides a nice abstraction for field retrieval in general. Note that this issue is different than #5172 which is an high hanging fruit and would require changes in the highlighter.The text was updated successfully, but these errors were encountered: