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

Indices Exists API missing include_type_name in REST API spec #43905

Closed
russcam opened this issue Jul 3, 2019 · 3 comments · Fixed by #43963
Closed

Indices Exists API missing include_type_name in REST API spec #43905

russcam opened this issue Jul 3, 2019 · 3 comments · Fixed by #43963
Assignees
Labels
:Search/Mapping Index mappings, including merging and defining field types v6.8.2

Comments

@russcam
Copy link
Contributor

russcam commented Jul 3, 2019

Issue

Relates: elastic/elasticsearch-net#3901

The REST API spec for indices.exists.json is missing include_type_name in 6.8.0:

"local": {
"type": "boolean",
"description": "Return local information, do not retrieve the state from master node (default: false)"
},
"ignore_unavailable": {
"type": "boolean",
"description": "Ignore unavailable indexes (default: false)"
},
"allow_no_indices": {
"type": "boolean",
"description": "Ignore if a wildcard expression resolves to no concrete indices (default: false)"
},
"expand_wildcards": {
"type": "enum",
"options": [ "open", "closed", "none", "all" ],
"default": "open",
"description": "Whether wildcard expressions should get expanded to open or closed indices (default: open)"
},
"flat_settings": {
"type": "boolean",
"description": "Return settings in flat format (default: false)"
},
"include_defaults": {
"type": "boolean",
"description": "Whether to return all default setting for each of the indices.",
"default": false
}

Sending an index exists request without include_type_name results in a Deprecation Warning HTTP header being returned:

Request

HEAD http://127.0.0.1:9200/foo HTTP/1.1
Accept: application/json
Content-Type: application/json
Host: 127.0.0.1:9200
Connection: Keep-Alive

Response

HTTP/1.1 200 OK
Warning: 299 Elasticsearch-6.8.1-1fad4e1 "[types removal] The parameter include_type_name should be explicitly specified in get indices requests to prepare for 7.0. In 7.0 include_type_name will default to 'false', which means responses will omit the type name in mapping definitions."
content-type: application/json; charset=UTF-8
content-length: 225

Sending a request with include_type_name=true or include_type_name=false results in no Deprecation Warning.

Feature

The indices.exists.json REST API spec should include include_type_name in the list of params, so that clients that generate API methods from the spec pick this up.

@cbuescher cbuescher added the :Search/Mapping Index mappings, including merging and defining field types label Jul 3, 2019
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-search

@cbuescher cbuescher self-assigned this Jul 3, 2019
cbuescher pushed a commit to cbuescher/elasticsearch that referenced this issue Jul 3, 2019
The parameter exists in the indices.get API already, they both map to the same
REST action. Although the response body for the HEAD request used for checking
existence is empty, the parameter can be used to avoid deprecation warnings and
should be added so clients that generate their API from the rest spec pick it
up.

Closes elastic#43905
cbuescher pushed a commit to cbuescher/elasticsearch that referenced this issue Jul 4, 2019
Currently we log a deprecation warning to the types removal in
RestGetIndicesAction even if the REST method is HEAD, which is used by the
indices.exists API. Since the body is empty in this case we should not need to
show the deprecation warning.

Closes elastic#43905
pull bot pushed a commit to scher200/elasticsearch that referenced this issue Jul 4, 2019
…c#43963)

Currently we log a deprecation warning to the types removal in
RestGetIndicesAction even if the REST method is HEAD, which is used by the
indices.exists API. Since the body is empty in this case we should not need to
show the deprecation warning.

Closes elastic#43905
cbuescher pushed a commit that referenced this issue Jul 4, 2019
Currently we log a deprecation warning to the types removal in
RestGetIndicesAction even if the REST method is HEAD, which is used by the
indices.exists API. Since the body is empty in this case we should not need to
show the deprecation warning.

Closes #43905
cbuescher pushed a commit that referenced this issue Jul 4, 2019
Currently we log a deprecation warning to the types removal in
RestGetIndicesAction even if the REST method is HEAD, which is used by the
indices.exists API. Since the body is empty in this case we should not need to
show the deprecation warning.

Closes #43905
cbuescher pushed a commit that referenced this issue Jul 4, 2019
Currently we log a deprecation warning to the types removal in
RestGetIndicesAction even if the REST method is HEAD, which is used by the
indices.exists API. Since the body is empty in this case we should not need to
show the deprecation warning.

Closes #43905
cbuescher pushed a commit to cbuescher/elasticsearch that referenced this issue Jul 4, 2019
…c#43963)

Currently we log a deprecation warning to the types removal in
RestGetIndicesAction even if the REST method is HEAD, which is used by the
indices.exists API. Since the body is empty in this case we should not need to
show the deprecation warning.

Closes elastic#43905
@cbuescher
Copy link
Member

@russcam instead of adding the parameter to the indices.exist API, we decided to rather prevent the deprecation log for the exists API (see discussion in #43910 and fix in #43963). Just backporting this to 6.8 now, if we do another minor release on that branch that might help the user. It doesn't really make sense to have this parameter in this API since the body is empty. Let me know if this you think this solved the issue or if we are missing something.

cbuescher pushed a commit to cbuescher/elasticsearch that referenced this issue Jul 4, 2019
…c#43963)

Currently we log a deprecation warning to the types removal in
RestGetIndicesAction even if the REST method is HEAD, which is used by the
indices.exists API. Since the body is empty in this case we should not need to
show the deprecation warning.

Closes elastic#43905
cbuescher pushed a commit that referenced this issue Jul 4, 2019
Currently we log a deprecation warning to the types removal in
RestGetIndicesAction even if the REST method is HEAD, which is used by the
indices.exists API. Since the body is empty in this case we should not need to
show the deprecation warning.

Closes #43905
@russcam
Copy link
Contributor Author

russcam commented Jul 5, 2019

Removing the deprecation warning for index.exists is a much better solution. Thanks for the fix @cbuescher 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Search/Mapping Index mappings, including merging and defining field types v6.8.2
Projects
None yet
3 participants