Elasticsearch: Guess field type from first non-empty value #32290
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ifrost
approved these changes
Mar 25, 2021
ryantxu
pushed a commit
that referenced
this pull request
Mar 30, 2021
ryantxu
pushed a commit
to dejapong/grafana
that referenced
this pull request
Mar 30, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What this PR does / why we need it:
When parsing an elasticsearch response, every field is treated as a string, which makes it impossible to, for example, work with thresholds in panels. With this change the field type is guessed from the first non-empty value in the returned document set.
Which issue(s) this PR fixes:
Fixes #29431
Special notes for your reviewer:
The solution is not perfect as in order to correctly know the type we should get the mappings for the current index.
This, for example, will detect time fields as string. a future improvement could be requesting the mapping when receiving the response in order to correctly assign the type, but given we want to migrate the response parser to the backend i'd leave this to a future implementaiton.