Mention dot-prefixed patterns in hidden index docs (#81464)

The hidden index docs did not mention that dot-prefixed patterns default
to matching hidden indices. This PR adds a note explaining the behavior
and why it's like that.
This commit is contained in:
Gordon Brown 2021-12-07 17:02:01 -07:00 committed by GitHub
parent dd1ed30731
commit 50794a1b51
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23

View file

@ -23,11 +23,11 @@ sent with a request. Responses are also UTF-8 encoded.
[[get-requests]]
=== GET and POST requests
A number of {es} GET APIs--most notably the search API--support a request body.
While the GET action makes sense in the context of retrieving information,
A number of {es} GET APIs--most notably the search API--support a request body.
While the GET action makes sense in the context of retrieving information,
GET requests with a body are not supported by all HTTP libraries.
All {es} GET APIs that require a body can also be submitted as POST requests.
Alternatively, you can pass the request body as the
Alternatively, you can pass the request body as the
<<api-request-body-query-string, `source` query string parameter>>
when using GET.
@ -177,6 +177,11 @@ For most APIs, wildcard expressions do not match hidden data streams and indices
by default. To match hidden data streams and indices using a wildcard
expression, you must specify the `expand_wildcards` query parameter.
Alternatively, querying an index pattern starting with a dot, such as
`.watcher_hist*`, will match hidden indices by default. This is intended to
mirror Unix file-globbing behavior and provide a smoother transition path to
hidden indices.
You can create hidden data streams by setting `data_stream.hidden` to `true` in
the stream's matching <<indices-put-template,index template>>. You can hide
indices using the <<index-hidden,`index.hidden`>> index setting.
@ -190,11 +195,11 @@ Global index templates that match all indices are not applied to hidden indices.
[[system-indices]]
==== System indices
{es} modules and plugins can store configuration and state information in internal _system indices_.
You should not directly access or modify system indices
{es} modules and plugins can store configuration and state information in internal _system indices_.
You should not directly access or modify system indices
as they contain data essential to the operation of the system.
IMPORTANT: Direct access to system indices is deprecated and
IMPORTANT: Direct access to system indices is deprecated and
will no longer be allowed in the next major version.
[discrete]
@ -218,25 +223,25 @@ of the source, such as `application/json`.
[[api-compatibility]]
=== REST API version compatibility
Major version upgrades often include a number of breaking changes
that impact how you interact with {es}.
While we recommend that you monitor the deprecation logs and
Major version upgrades often include a number of breaking changes
that impact how you interact with {es}.
While we recommend that you monitor the deprecation logs and
update applications before upgrading {es},
having to coordinate the necessary changes can be an impediment to upgrading.
having to coordinate the necessary changes can be an impediment to upgrading.
You can enable an existing application to function without modification after
an upgrade by including API compatibility headers, which tell {es} you are still
using the previous version of the REST API. Using these headers allows the
using the previous version of the REST API. Using these headers allows the
structure of requests and responses to remain the same; it does not guarantee
the same behavior.
the same behavior.
You set version compatibility on a per-request basis in the `Content-Type` and `Accept` headers.
Setting `compatible-with` to the same major version as
the version you're running has no impact,
but ensures that the request will still work after {es} is upgraded.
You set version compatibility on a per-request basis in the `Content-Type` and `Accept` headers.
Setting `compatible-with` to the same major version as
the version you're running has no impact,
but ensures that the request will still work after {es} is upgraded.
To tell {es} 8.0 you are using the 7.x request and response format,
To tell {es} 8.0 you are using the 7.x request and response format,
set `compatible-with=7`:
[source,sh]