Fixing handling of subobject mappings in simulate ingest API #132046
Conversation
masseyke
added
>bug
:Data Management/Ingest Node
|
Pinging @elastic/es-data-management (Team:Data Management) |
|
Hi @masseyke, I've created a changelog YAML for you. |
elasticsearchmachine
added
the
Team:Data Management
| @@ -351,7 +351,7 @@ private Collection<String> validateUpdatedMappings( | |||
| .putMapping(new MappingMetadata(updatedMappings)) | |||
| .build(); | |||
| Engine.Index result = indicesService.withTempIndexService(originalIndexMetadata, indexService -> { | |||
| indexService.mapperService().merge(updatedIndexMetadata, MapperService.MergeReason.MAPPING_UPDATE); | |||
| indexService.mapperService().merge(updatedIndexMetadata, MapperService.MergeReason.INDEX_TEMPLATE); | |||
There was a problem hiding this comment.
Hmm… I'm worried we kind of want both behaviors right? The MAPPING_UPDATE one is if we were to update the mapping via the API, while the INDEX_TEMPLATE one is for updating the template. Do we know for sure what the intent is on the user's side?
There was a problem hiding this comment.
My thinking was that if a user wanted to simulate this change, they'd be doing it through an index-template-like update rather than a mapping update, since this change just fails with a mapping update. This API is meant to simulate what would happen if the index had this mapping change, rather than what would happen if I attempted to make this mapping change.
|
Hi @masseyke, I've updated the changelog YAML for you. |
|
I'm closing this one in favor of the approach given in #132210. |
This correctly replaces mappings for subobjects rather than attempting to merge them in the simulate ingest API.
This fixes the problem in the description of #131608, but does not address the problem described in a comment in that issue, which appears to be different.