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
Conditional highlighting #4649
Comments
Adds a "conditional" object under each highlighting field that can contain other fields. Those fields are highlighted based on if there was a match in the containing field. It'll let you do things like this example in the docs: This example extracts extracts the first 100 characters from `text` if there is a match in `title`, otherwise it highlights `text` as normal. { "highlight": { "fields": { "title": { "conditional": { "match": { "text": { "no_match_size": 100, "skip_matching": true } } "no_match": { "text": { "no_match_size": 100 } }, } } } } } Also adds a setting to instruct the highlighter to skip its normal match logic and just do its no_match_size stuff. This is very useful with conditional highlighting "chains" that end in a no_match_size extracting a previous entry in the chain. Like this example from the docs: { "highlight": { "fields": { "text": { "conditional": { "no_match": { "auxiliary_text": { "conditional": { "no_match": { "file_text": { "conditional": { "no_match": { "text": { "no_match_size": 100, "skip_matching": true } } } } } } } } } } } } } Closes elastic#4649
I picked this back up after doing some performance testing. I found out that highlighting if one of the heaviest consumers of CPU for my use case. So I figured anything that I can do to lower it would be useful. This could allow you to skip highlighting some fields entirely. Implemented this with a different api. It looks like: {
"highlight": {
"fields": {
"title": {
"conditional": {
"match": {
"text": {
"no_match_size": 100,
"skip_matching": true
}
}
"no_match": {
"text": {
"no_match_size": 100
}
},
}
}
}
}
} Each field can contain a |
Adds a "conditional" object under each highlighting field that can contain other fields. Those fields are highlighted based on if there was a match in the containing field. It'll let you do things like this example in the docs: This example extracts extracts the first 100 characters from `text` if there is a match in `title`, otherwise it highlights `text` as normal. { "highlight": { "fields": { "title": { "conditional": { "match": { "text": { "no_match_size": 100, "skip_matching": true } } "no_match": { "text": { "no_match_size": 100 } }, } } } } } Also adds a setting to instruct the highlighter to skip its normal match logic and just do its no_match_size stuff. This is very useful with conditional highlighting "chains" that end in a no_match_size extracting a previous entry in the chain. Like this example from the docs: { "highlight": { "fields": { "text": { "conditional": { "no_match": { "auxiliary_text": { "conditional": { "no_match": { "file_text": { "conditional": { "no_match": { "text": { "no_match_size": 100, "skip_matching": true } } } } } } } } } } } } } Closes elastic#4649
Because json objects are unordered this also adds an explicit order syntax that looks like "highlight": { "fields": [ {"title":{ /*params*/ }}, {"text":{ /*params*/ }} ] } This is not useful for any of the builtin highlighters but will be useful in plugins. Closes elastic#4649
Because json objects are unordered this also adds an explicit order syntax that looks like "highlight": { "fields": [ {"title":{ /*params*/ }}, {"text":{ /*params*/ }} ] } This is not useful for any of the builtin highlighters but will be useful in plugins. Closes #4649
I highlight two fields but only use the highlighting from one of them if there aren't matches in the first field. I think it'd be cool not to highlight the second field at all if there is a match in the first field. Mostly I like this idea because that second field is typically much much larger than the first field and takes some time to highlight.
or
Note that I really only need that no match snippet from the first field if there aren't matches in either field but it felt simpler to declare it on the first field.
I'll happy to implement this but would some thoughts on my proposed api.
The text was updated successfully, but these errors were encountered: