Skip to content

Conversation

@pgomulka
Copy link
Contributor

@pgomulka pgomulka commented Apr 23, 2021

Implements a V7 compatible typed endpoints for REST for search related apis
retrofits the REST layer change removed in #41640

relates main meta issue #51816
relates types removal issue #54160

@pgomulka pgomulka added the WIP label Apr 23, 2021
@pgomulka pgomulka changed the title DRAFT Compat/search2 [Rest Api Compatibility] Typed endpoints for search and related endpoints May 10, 2021
@pgomulka pgomulka added :Core/Infra/REST API REST infrastructure and utilities :Search/Search Search-related issues that do not fall into other categories v8.0.0 and removed WIP labels May 10, 2021
@pgomulka pgomulka self-assigned this May 10, 2021
@pgomulka pgomulka marked this pull request as ready for review May 10, 2021 15:59
@elasticmachine elasticmachine added Team:Core/Infra Meta label for core/infra team Team:Search Meta label for search team labels May 10, 2021
@elasticmachine
Copy link
Collaborator

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

@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-search (Team:Search)

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 from a search perspective.

NamedWriteableRegistry namedWriteableRegistry,
IntConsumer setSize) throws IOException {
if (request.getRestApiVersion() == RestApiVersion.V_7 &&
(request.hasParam(INCLUDE_TYPE_NAME_PARAMETER) || request.hasParam("type"))) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Does include_type_name actually have an effect 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, it is not needed. I mistakenly assumed that it is needed as other APIs so far were expecting it.
I removed it

//possibly this needs a separate issue to track the problem
// if we emit a compatible warning when a type parameter (?type=some_type) is present,
// then for APIs where a {type} is used a compatible warning would be emitted twice
// this is because we cannot distinguish between them and for {type} we already emit a warning when using a Route
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 is fine? If you specify the type in two places you get two warnings.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I probably did not made this clear. The problem is that you would get two warnings when specifying the type in {type} as in path.
The problem only occurs when an expected paramter ?type has the same name as the parameter in braces {type}

@pgomulka pgomulka merged commit 85ed910 into elastic:master May 12, 2021
@pgomulka pgomulka mentioned this pull request May 14, 2021
66 tasks
pgomulka added a commit to pgomulka/elasticsearch that referenced this pull request May 14, 2021
enabeling the tests and adds a type field for termvector response the commit that enabled typed enpoints but missed to update the response elastic#72155
pgomulka added a commit that referenced this pull request May 19, 2021
Enabling the tests and adds a type field for termvector response the commit that enabled typed endpoints but missed to update the response #72155
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 :Search/Search Search-related issues that do not fall into other categories Team:Core/Infra Meta label for core/infra team Team:Search Meta label for search team v8.0.0-alpha1

4 participants