[ML] Changes default destination index field mapping and adds scripted_metric agg (#40750) #40846
Conversation
This file contains hidden or 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
…d_metric agg (elastic#40750) * [ML] Allowing destination index mappings to have dynamic types, adds script_metric agg * Making dynamic|source mapping explicit
Collaborator
|
Pinging @elastic/ml-core |
Member
Author
|
run elasticsearch-ci/2 |
benwtrent
deleted the
feature/data-frame-allow-dynamic-mapped-types-add-scripted-metric-7.x
branch
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
This PR adjusts the default behavior for aggregations whose destination mapping cannot be accurately determined either through agg type or source field mapping. Previously, setting the field mapping to double was the default behavior. This will not work for more complex scenarios. So, instead of enforcing an explicit mapping for indeterminable fields, I allow the mapping to dynamically determine the appropriate type.
The reason for adding scripted_metric in this PR as well, is so we have an aggregation that will exercise the new default behavior code path.
I did NOT attempt to determine the explicit mapping for scripted_metric and simply let it always be dynamic. The reasoning for this is that we would simply be doing what the ES mapping system already does for us. It would add complexity with little benefit.
Also, this simply adds the support for the aggregation. This PR does NOT include any new abstractions, interfaces, fields, etc. in the API. If we want to obfuscate the complexities in the scripted_metric aggregation, that will have to be future work.
Backport of: #40750