Skip to content
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

[Rest Compatible Api] include_type_name parameter #70966

Merged
merged 43 commits into from
Apr 19, 2021

Conversation

pgomulka
Copy link
Contributor

@pgomulka pgomulka commented Mar 29, 2021

This commit allows to use the include_type_name parameter with the compatible rest api.
The support for include_type_name was previously removed in #48632

relates #51816
types removal meta issue #54160

@pgomulka
Copy link
Contributor Author

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.

@pgomulka pgomulka self-assigned this Mar 31, 2021
@pgomulka pgomulka added the :Core/Infra/REST API REST infrastructure and utilities label Mar 31, 2021
@pgomulka pgomulka marked this pull request as ready for review March 31, 2021 14:18
@elasticmachine elasticmachine added the Team:Core/Infra Meta label for core/infra team label Mar 31, 2021
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-core-infra (Team:Core/Infra)

@pgomulka pgomulka requested a review from jtibshirani March 31, 2021 14:36
rest-api-spec/build.gradle Show resolved Hide resolved
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)) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@@ -378,7 +379,9 @@ private static void toInnerXContent(IndexTemplateMetadata indexTemplateMetadata,
indexTemplateMetadata.settings().toXContent(builder, params);
builder.endObject();

includeTypeName &= (params.paramAsBoolean("reduce_mappings", false) == false);
if(builder.getRestApiVersion() != RestApiVersion.V_7) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can this be onOrAfter V_8 ? (minor preference to avoid using 'not a specific version')

@@ -40,6 +41,13 @@
*/
public abstract class BaseRestHandler implements RestHandler {

/**
* 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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@jakelandis
Copy link
Contributor

Changes LGTM, assuming Julie and/or Alan and CI agree.

@jakelandis
Copy link
Contributor

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);
}
Copy link
Contributor Author

@pgomulka pgomulka Apr 15, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

@romseygeek romseygeek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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);
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

++ let's keep it for now and I can look at removing it in a followup

@@ -65,7 +68,12 @@ public XContentBuilder toXContent(XContentBuilder builder, Params params) throws

builder.startObject();
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)) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@@ -49,6 +58,12 @@ public RestChannelConsumer prepareRequest(final RestRequest request, final NodeC
final String[] indices = Strings.splitStringByCommaToArray(request.param("index"));
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);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need to call paramAsBoolean here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggestion: s/isIncludeTypeName/includeTypeName/

@jtibshirani
Copy link
Contributor

I didn't have the chance to go over each file carefully, but it looks good to me overall -- no objections to merging!

@pgomulka pgomulka merged commit 3ef5e4c into elastic:master Apr 19, 2021
@pgomulka pgomulka mentioned this pull request May 10, 2021
66 tasks
pgomulka added a commit to pgomulka/elasticsearch that referenced this pull request Jul 19, 2021
…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
pgomulka added a commit that referenced this pull request Jul 19, 2021
…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
ywangd pushed a commit to ywangd/elasticsearch that referenced this pull request Jul 30, 2021
…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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Core/Infra/REST API REST infrastructure and utilities Team:Core/Infra Meta label for core/infra team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants