mirror of
https://github.com/elastic/elasticsearch.git
synced 2025-06-28 17:34:17 -04:00
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:
parent
dd1ed30731
commit
50794a1b51
1 changed files with 22 additions and 17 deletions
|
@ -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]
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue