[Rest Compatible Api] include_type_name parameter#70966
[Rest Compatible Api] include_type_name parameter#70966pgomulka merged 43 commits intoelastic:masterfrom
Conversation
|
FYI - you can ignore build/test transformation part. This is handled in a PR that will be merged before this one. I did not wanted to block testing of this PR though so I included it for the time being. |
|
Pinging @elastic/es-core-infra (Team:Core/Infra) |
| PARSER.declareField((parser, request, context) -> { | ||
| // a type is not included, add a dummy _doc type | ||
| Map<String, Object> mappings = parser.map(); | ||
| if (MapperService.isMappingSourceTyped(MapperService.SINGLE_MAPPING_NAME, mappings)) { |
There was a problem hiding this comment.
Building on what I said in a previous comment -- these were added in #38270 to catch an important case that mapping parsing wasn't able to detect. But there have been substantial improvements/ refactors to mapping parsing since then, so we may be able to remove these checks and have the tests still pass. To keep this PR a straightforward 'restore' of old logic, maybe we could look into removing these checks in a follow-up.
| builder.endObject(); | ||
|
|
||
| includeTypeName &= (params.paramAsBoolean("reduce_mappings", false) == false); | ||
| if(builder.getRestApiVersion() != RestApiVersion.V_7) { |
There was a problem hiding this comment.
can this be onOrAfter V_8 ? (minor preference to avoid using 'not a specific version')
|
|
||
| /** | ||
| * Parameter that controls whether certain REST apis should include type names in their requests or responses. | ||
| * Note: This parameter is only available through compatible rest api. |
There was a problem hiding this comment.
might want to reference the V_7 constant in the java doc ... i think the build will fail if you reference something that is not there and will help to find this when it is time to re-remove.
|
Changes LGTM, assuming Julie and/or Alan and CI agree. |
|
The compat test failures should be fixed if you merge in master. |
| includeTypeName &= (params.paramAsBoolean("reduce_mappings", false) == false); | ||
| if(builder.getRestApiVersion().matches(onOrAfter(V_8))) { | ||
| includeTypeName &= (params.paramAsBoolean("reduce_mappings", false) == false); | ||
| } |
There was a problem hiding this comment.
@romseygeek do you think there need to be a special handing for this in V7 mode?
The logic for 7.x was more complex, but it feels like it was a behaviour change
There was a problem hiding this comment.
I think this reduce_mappings parameter is only set internally, so I don't think we want to put a Rest API version guard on it. It's for things like template upgrades or building internal indexes from templates.
romseygeek
left a comment
There was a problem hiding this comment.
LGTM - a couple of minor nits and one suggested change, but I'm happy after that if CI is.
| includeTypeName &= (params.paramAsBoolean("reduce_mappings", false) == false); | ||
| if(builder.getRestApiVersion().matches(onOrAfter(V_8))) { | ||
| includeTypeName &= (params.paramAsBoolean("reduce_mappings", false) == false); | ||
| } |
There was a problem hiding this comment.
I think this reduce_mappings parameter is only set internally, so I don't think we want to put a Rest API version guard on it. It's for things like template upgrades or building internal indexes from templates.
| PARSER.declareField((parser, request, context) -> { | ||
| // a type is not included, add a dummy _doc type | ||
| Map<String, Object> mappings = parser.map(); | ||
| if (MapperService.isMappingSourceTyped(MapperService.SINGLE_MAPPING_NAME, mappings)) { |
There was a problem hiding this comment.
++ let's keep it for now and I can look at removing it in a followup
| for (IndexTemplateMetadata indexTemplateMetadata : getIndexTemplates()) { | ||
| IndexTemplateMetadata.Builder.toXContent(indexTemplateMetadata, builder, params); | ||
| if(builder.getRestApiVersion() == RestApiVersion.V_7 && | ||
| params.paramAsBoolean(INCLUDE_TYPE_NAME_PARAMETER, DEFAULT_INCLUDE_TYPE_NAME_POLICY)) { |
There was a problem hiding this comment.
I think I'd prefer an explicit false as the default value here to make it clearer that the normal path is to not output types.
| final String[] fields = Strings.splitStringByCommaToArray(request.param("fields")); | ||
|
|
||
| if (request.getRestApiVersion() == RestApiVersion.V_7 && request.hasParam(INCLUDE_TYPE_NAME_PARAMETER)) { | ||
| request.paramAsBoolean(INCLUDE_TYPE_NAME_PARAMETER, DEFAULT_INCLUDE_TYPE_NAME_POLICY); |
There was a problem hiding this comment.
Why do we need to call paramAsBoolean here?
There was a problem hiding this comment.
good point, the value is ignored. Will fix to just use param
| return channel -> client.admin().indices().rolloverIndex(rolloverIndexRequest, new RestToXContentListener<>(channel)); | ||
| } | ||
|
|
||
| private boolean isIncludeTypeName(RestRequest request) { |
There was a problem hiding this comment.
suggestion: s/isIncludeTypeName/includeTypeName/
|
I didn't have the chance to go over each file carefully, but it looks good to me overall -- no objections to merging! |
…plate
Previously the compatibility layer was alwayre returning an _doc for get
template.
This commit does not return _doc in mappings when mappings are empty.
Returning just {} empty object
also moving term lookups tests which are already fixed (relates elastic#74544)
relates elastic#70966
relates main meta issue elastic#51816
relates types removal meta elastic#54160
…plate (#75448) Previously the compatibility layer was always returning an _doc in mappings for get template. This commit does not return _doc in empty mappings. Returning just {} empty object (v7 and v8 behaviour) also moving term lookups tests which are already fixed (relates #74544) relates #70966 relates main meta issue #51816 relates types removal meta #54160
…plate (elastic#75448) Previously the compatibility layer was always returning an _doc in mappings for get template. This commit does not return _doc in empty mappings. Returning just {} empty object (v7 and v8 behaviour) also moving term lookups tests which are already fixed (relates elastic#74544) relates elastic#70966 relates main meta issue elastic#51816 relates types removal meta elastic#54160
This commit allows to use the
include_type_nameparameter with the compatible rest api.The support for
include_type_namewas previously removed in #48632relates #51816
types removal meta issue #54160