diff --git a/output/openapi/elasticsearch-openapi.json b/output/openapi/elasticsearch-openapi.json index 4f2c05557a..cedee4a480 100644 --- a/output/openapi/elasticsearch-openapi.json +++ b/output/openapi/elasticsearch-openapi.json @@ -31828,7 +31828,11 @@ "rollup" ], "summary": "Search rolled-up data", - "description": "The rollup search endpoint is needed because, internally, rolled-up documents utilize a different document structure than the original data.\nIt rewrites standard Query DSL into a format that matches the rollup documents then takes the response and rewrites it back to what a client would expect given the original query.\n\nThe request body supports a subset of features from the regular search API.\nThe following functionality is not available:\n\n`size`: Because rollups work on pre-aggregated data, no search hits can be returned and so size must be set to zero or omitted entirely.\n`highlighter`, `suggestors`, `post_filter`, `profile`, `explain`: These are similarly disallowed.\n\n**Searching both historical rollup and non-rollup data**\n\nThe rollup search API has the capability to search across both \"live\" non-rollup data and the aggregated rollup data.\nThis is done by simply adding the live indices to the URI. For example:\n\n```\nGET sensor-1,sensor_rollup/_rollup_search\n{\n \"size\": 0,\n \"aggregations\": {\n \"max_temperature\": {\n \"max\": {\n \"field\": \"temperature\"\n }\n }\n }\n}\n```\n\nThe rollup search endpoint does two things when the search runs:\n\n* The original request is sent to the non-rollup index unaltered.\n* A rewritten version of the original request is sent to the rollup index.\n\nWhen the two responses are received, the endpoint rewrites the rollup response and merges the two together.\nDuring the merging process, if there is any overlap in buckets between the two responses, the buckets from the non-rollup index are used.", + "description": "The rollup search endpoint is needed because, internally, rolled-up documents utilize a different document structure than the original data.\nIt rewrites standard Query DSL into a format that matches the rollup documents then takes the response and rewrites it back to what a client would expect given the original query.\n\nThe request body supports a subset of features from the regular search API.\nThe following functionality is not available:\n\n`size`: Because rollups work on pre-aggregated data, no search hits can be returned and so size must be set to zero or omitted entirely.\n`highlighter`, `suggestors`, `post_filter`, `profile`, `explain`: These are similarly disallowed.\n\nFor more detailed examples of using the rollup search API, including querying rolled-up data only or combining rolled-up and live data, refer to the External documentation.", + "externalDocs": { + "url": "https://www.elastic.co/docs/manage-data/lifecycle/rollup/getting-started-api#historical-only-search-example", + "x-previousVersionUrl": "https://www.elastic.co/guide/en/elasticsearch/reference/8.18/rollup-search.html" + }, "operationId": "rollup-rollup-search", "parameters": [ { @@ -31858,7 +31862,11 @@ "rollup" ], "summary": "Search rolled-up data", - "description": "The rollup search endpoint is needed because, internally, rolled-up documents utilize a different document structure than the original data.\nIt rewrites standard Query DSL into a format that matches the rollup documents then takes the response and rewrites it back to what a client would expect given the original query.\n\nThe request body supports a subset of features from the regular search API.\nThe following functionality is not available:\n\n`size`: Because rollups work on pre-aggregated data, no search hits can be returned and so size must be set to zero or omitted entirely.\n`highlighter`, `suggestors`, `post_filter`, `profile`, `explain`: These are similarly disallowed.\n\n**Searching both historical rollup and non-rollup data**\n\nThe rollup search API has the capability to search across both \"live\" non-rollup data and the aggregated rollup data.\nThis is done by simply adding the live indices to the URI. For example:\n\n```\nGET sensor-1,sensor_rollup/_rollup_search\n{\n \"size\": 0,\n \"aggregations\": {\n \"max_temperature\": {\n \"max\": {\n \"field\": \"temperature\"\n }\n }\n }\n}\n```\n\nThe rollup search endpoint does two things when the search runs:\n\n* The original request is sent to the non-rollup index unaltered.\n* A rewritten version of the original request is sent to the rollup index.\n\nWhen the two responses are received, the endpoint rewrites the rollup response and merges the two together.\nDuring the merging process, if there is any overlap in buckets between the two responses, the buckets from the non-rollup index are used.", + "description": "The rollup search endpoint is needed because, internally, rolled-up documents utilize a different document structure than the original data.\nIt rewrites standard Query DSL into a format that matches the rollup documents then takes the response and rewrites it back to what a client would expect given the original query.\n\nThe request body supports a subset of features from the regular search API.\nThe following functionality is not available:\n\n`size`: Because rollups work on pre-aggregated data, no search hits can be returned and so size must be set to zero or omitted entirely.\n`highlighter`, `suggestors`, `post_filter`, `profile`, `explain`: These are similarly disallowed.\n\nFor more detailed examples of using the rollup search API, including querying rolled-up data only or combining rolled-up and live data, refer to the External documentation.", + "externalDocs": { + "url": "https://www.elastic.co/docs/manage-data/lifecycle/rollup/getting-started-api#historical-only-search-example", + "x-previousVersionUrl": "https://www.elastic.co/guide/en/elasticsearch/reference/8.18/rollup-search.html" + }, "operationId": "rollup-rollup-search-1", "parameters": [ { @@ -44217,7 +44225,11 @@ "document" ], "summary": "Update a document", - "description": "Update a document by running a script or passing a partial document.\n\nIf the Elasticsearch security features are enabled, you must have the `index` or `write` index privilege for the target index or index alias.\n\nThe script can update, delete, or skip modifying the document.\nThe API also supports passing a partial document, which is merged into the existing document.\nTo fully replace an existing document, use the index API.\nThis operation:\n\n* Gets the document (collocated with the shard) from the index.\n* Runs the specified script.\n* Indexes the result.\n\nThe document must still be reindexed, but using this API removes some network roundtrips and reduces chances of version conflicts between the GET and the index operation.\n\nThe `_source` field must be enabled to use this API.\nIn addition to `_source`, you can access the following variables through the `ctx` map: `_index`, `_type`, `_id`, `_version`, `_routing`, and `_now` (the current timestamp).\n\n## Required authorization\n\n* Index privileges: `write`\n", + "description": "Update a document by running a script or passing a partial document.\n\nIf the Elasticsearch security features are enabled, you must have the `index` or `write` index privilege for the target index or index alias.\n\nThe script can update, delete, or skip modifying the document.\nThe API also supports passing a partial document, which is merged into the existing document.\nTo fully replace an existing document, use the index API.\nThis operation:\n\n* Gets the document (collocated with the shard) from the index.\n* Runs the specified script.\n* Indexes the result.\n\nThe document must still be reindexed, but using this API removes some network roundtrips and reduces chances of version conflicts between the GET and the index operation.\n\nThe `_source` field must be enabled to use this API.\nIn addition to `_source`, you can access the following variables through the `ctx` map: `_index`, `_type`, `_id`, `_version`, `_routing`, and `_now` (the current timestamp).\nFor usage examples such as partial updates, upserts, and scripted updates, see the External documentation.\n\n## Required authorization\n\n* Index privileges: `write`\n", + "externalDocs": { + "url": "https://www.elastic.co/docs/reference/elasticsearch/rest-apis/update-document", + "x-previousVersionUrl": "https://www.elastic.co/guide/en/elasticsearch/reference/8.18/docs-update.html" + }, "operationId": "update", "parameters": [ { @@ -44500,7 +44512,11 @@ "document" ], "summary": "Update documents", - "description": "Updates documents that match the specified query.\nIf no query is specified, performs an update on every document in the data stream or index without modifying the source, which is useful for picking up mapping changes.\n\nIf the Elasticsearch security features are enabled, you must have the following index privileges for the target data stream, index, or alias:\n\n* `read`\n* `index` or `write`\n\nYou can specify the query criteria in the request URI or the request body using the same syntax as the search API.\n\nWhen you submit an update by query request, Elasticsearch gets a snapshot of the data stream or index when it begins processing the request and updates matching documents using internal versioning.\nWhen the versions match, the document is updated and the version number is incremented.\nIf a document changes between the time that the snapshot is taken and the update operation is processed, it results in a version conflict and the operation fails.\nYou can opt to count version conflicts instead of halting and returning by setting `conflicts` to `proceed`.\nNote that if you opt to count version conflicts, the operation could attempt to update more documents from the source than `max_docs` until it has successfully updated `max_docs` documents or it has gone through every document in the source query.\n\nNOTE: Documents with a version equal to 0 cannot be updated using update by query because internal versioning does not support 0 as a valid version number.\n\nWhile processing an update by query request, Elasticsearch performs multiple search requests sequentially to find all of the matching documents.\nA bulk update request is performed for each batch of matching documents.\nAny query or update failures cause the update by query request to fail and the failures are shown in the response.\nAny update requests that completed successfully still stick, they are not rolled back.\n\n**Throttling update requests**\n\nTo control the rate at which update by query issues batches of update operations, you can set `requests_per_second` to any positive decimal number.\nThis pads each batch with a wait time to throttle the rate.\nSet `requests_per_second` to `-1` to turn off throttling.\n\nThrottling uses a wait time between batches so that the internal scroll requests can be given a timeout that takes the request padding into account.\nThe padding time is the difference between the batch size divided by the `requests_per_second` and the time spent writing.\nBy default the batch size is 1000, so if `requests_per_second` is set to `500`:\n\n```\ntarget_time = 1000 / 500 per second = 2 seconds\nwait_time = target_time - write_time = 2 seconds - .5 seconds = 1.5 seconds\n```\n\nSince the batch is issued as a single _bulk request, large batch sizes cause Elasticsearch to create many requests and wait before starting the next set.\nThis is \"bursty\" instead of \"smooth\".\n\n**Slicing**\n\nUpdate by query supports sliced scroll to parallelize the update process.\nThis can improve efficiency and provide a convenient way to break the request down into smaller parts.\n\nSetting `slices` to `auto` chooses a reasonable number for most data streams and indices.\nThis setting will use one slice per shard, up to a certain limit.\nIf there are multiple source data streams or indices, it will choose the number of slices based on the index or backing index with the smallest number of shards.\n\nAdding `slices` to `_update_by_query` just automates the manual process of creating sub-requests, which means it has some quirks:\n\n* You can see these requests in the tasks APIs. These sub-requests are \"child\" tasks of the task for the request with slices.\n* Fetching the status of the task for the request with `slices` only contains the status of completed slices.\n* These sub-requests are individually addressable for things like cancellation and rethrottling.\n* Rethrottling the request with `slices` will rethrottle the unfinished sub-request proportionally.\n* Canceling the request with slices will cancel each sub-request.\n* Due to the nature of slices each sub-request won't get a perfectly even portion of the documents. All documents will be addressed, but some slices may be larger than others. Expect larger slices to have a more even distribution.\n* Parameters like `requests_per_second` and `max_docs` on a request with slices are distributed proportionally to each sub-request. Combine that with the point above about distribution being uneven and you should conclude that using `max_docs` with `slices` might not result in exactly `max_docs` documents being updated.\n* Each sub-request gets a slightly different snapshot of the source data stream or index though these are all taken at approximately the same time.\n\nIf you're slicing manually or otherwise tuning automatic slicing, keep in mind that:\n\n* Query performance is most efficient when the number of slices is equal to the number of shards in the index or backing index. If that number is large (for example, 500), choose a lower number as too many slices hurts performance. Setting slices higher than the number of shards generally does not improve efficiency and adds overhead.\n* Update performance scales linearly across available resources with the number of slices.\n\nWhether query or update performance dominates the runtime depends on the documents being reindexed and cluster resources.\n\n**Update the document source**\n\nUpdate by query supports scripts to update the document source.\nAs with the update API, you can set `ctx.op` to change the operation that is performed.\n\nSet `ctx.op = \"noop\"` if your script decides that it doesn't have to make any changes.\nThe update by query operation skips updating the document and increments the `noop` counter.\n\nSet `ctx.op = \"delete\"` if your script decides that the document should be deleted.\nThe update by query operation deletes the document and increments the `deleted` counter.\n\nUpdate by query supports only `index`, `noop`, and `delete`.\nSetting `ctx.op` to anything else is an error.\nSetting any other field in `ctx` is an error.\nThis API enables you to only modify the source of matching documents; you cannot move them.\n\n## Required authorization\n\n* Index privileges: `read`,`write`\n", + "description": "Updates documents that match the specified query.\nIf no query is specified, performs an update on every document in the data stream or index without modifying the source, which is useful for picking up mapping changes.\n\nIf the Elasticsearch security features are enabled, you must have the following index privileges for the target data stream, index, or alias:\n\n* `read`\n* `index` or `write`\n\nYou can specify the query criteria in the request URI or the request body using the same syntax as the search API.\n\nWhen you submit an update by query request, Elasticsearch gets a snapshot of the data stream or index when it begins processing the request and updates matching documents using internal versioning.\nWhen the versions match, the document is updated and the version number is incremented.\nIf a document changes between the time that the snapshot is taken and the update operation is processed, it results in a version conflict and the operation fails.\nYou can opt to count version conflicts instead of halting and returning by setting `conflicts` to `proceed`.\nNote that if you opt to count version conflicts, the operation could attempt to update more documents from the source than `max_docs` until it has successfully updated `max_docs` documents or it has gone through every document in the source query.\n\nNOTE: Documents with a version equal to 0 cannot be updated using update by query because internal versioning does not support 0 as a valid version number.\n\nWhile processing an update by query request, Elasticsearch performs multiple search requests sequentially to find all of the matching documents.\nA bulk update request is performed for each batch of matching documents.\nAny query or update failures cause the update by query request to fail and the failures are shown in the response.\nAny update requests that completed successfully still stick, they are not rolled back.\n\n**Refreshing shards**\n\nSpecifying the `refresh` parameter refreshes all shards once the request completes.\nThis is different to the update API's `refresh` parameter, which causes only the shard\nthat received the request to be refreshed. Unlike the update API, it does not support\n`wait_for`.\n\n**Running update by query asynchronously**\n\nIf the request contains `wait_for_completion=false`, Elasticsearch\nperforms some preflight checks, launches the request, and returns a\n[task](https://www.elastic.co/docs/api/doc/elasticsearch/group/endpoint-tasks) you can use to cancel or get the status of the task.\nElasticsearch creates a record of this task as a document at `.tasks/task/${taskId}`.\n\n**Waiting for active shards**\n\n`wait_for_active_shards` controls how many copies of a shard must be active\nbefore proceeding with the request. See [`wait_for_active_shards`](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-create#operation-create-wait_for_active_shards)\nfor details. `timeout` controls how long each write request waits for unavailable\nshards to become available. Both work exactly the way they work in the\n[Bulk API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-bulk). Update by query uses scrolled searches, so you can also\nspecify the `scroll` parameter to control how long it keeps the search context\nalive, for example `?scroll=10m`. The default is 5 minutes.\n\n**Throttling update requests**\n\nTo control the rate at which update by query issues batches of update operations, you can set `requests_per_second` to any positive decimal number.\nThis pads each batch with a wait time to throttle the rate.\nSet `requests_per_second` to `-1` to turn off throttling.\n\nThrottling uses a wait time between batches so that the internal scroll requests can be given a timeout that takes the request padding into account.\nThe padding time is the difference between the batch size divided by the `requests_per_second` and the time spent writing.\nBy default the batch size is 1000, so if `requests_per_second` is set to `500`:\n\n```\ntarget_time = 1000 / 500 per second = 2 seconds\nwait_time = target_time - write_time = 2 seconds - .5 seconds = 1.5 seconds\n```\n\nSince the batch is issued as a single _bulk request, large batch sizes cause Elasticsearch to create many requests and wait before starting the next set.\nThis is \"bursty\" instead of \"smooth\".\n\n**Slicing**\n\nUpdate by query supports sliced scroll to parallelize the update process.\nThis can improve efficiency and provide a convenient way to break the request down into smaller parts.\n\nSetting `slices` to `auto` chooses a reasonable number for most data streams and indices.\nThis setting will use one slice per shard, up to a certain limit.\nIf there are multiple source data streams or indices, it will choose the number of slices based on the index or backing index with the smallest number of shards.\n\nAdding `slices` to `_update_by_query` just automates the manual process of creating sub-requests, which means it has some quirks:\n\n* You can see these requests in the tasks APIs. These sub-requests are \"child\" tasks of the task for the request with slices.\n* Fetching the status of the task for the request with `slices` only contains the status of completed slices.\n* These sub-requests are individually addressable for things like cancellation and rethrottling.\n* Rethrottling the request with `slices` will rethrottle the unfinished sub-request proportionally.\n* Canceling the request with slices will cancel each sub-request.\n* Due to the nature of slices each sub-request won't get a perfectly even portion of the documents. All documents will be addressed, but some slices may be larger than others. Expect larger slices to have a more even distribution.\n* Parameters like `requests_per_second` and `max_docs` on a request with slices are distributed proportionally to each sub-request. Combine that with the point above about distribution being uneven and you should conclude that using `max_docs` with `slices` might not result in exactly `max_docs` documents being updated.\n* Each sub-request gets a slightly different snapshot of the source data stream or index though these are all taken at approximately the same time.\n\nIf you're slicing manually or otherwise tuning automatic slicing, keep in mind that:\n\n* Query performance is most efficient when the number of slices is equal to the number of shards in the index or backing index. If that number is large (for example, 500), choose a lower number as too many slices hurts performance. Setting slices higher than the number of shards generally does not improve efficiency and adds overhead.\n* Update performance scales linearly across available resources with the number of slices.\n\nWhether query or update performance dominates the runtime depends on the documents being reindexed and cluster resources.\nRefer to the linked documentation for examples of how to update documents using the `_update_by_query` API:\n\n## Required authorization\n\n* Index privileges: `read`,`write`\n", + "externalDocs": { + "url": "https://www.elastic.co/docs/reference/elasticsearch/rest-apis/update-by-query-api", + "x-previousVersionUrl": "https://www.elastic.co/guide/en/elasticsearch/reference/8.18/docs-update-by-query.html" + }, "operationId": "update-by-query", "parameters": [ { @@ -56455,7 +56471,7 @@ "type": "boolean" }, "pruning_config": { - "$ref": "#/components/schemas/_types.query_dsl.TokenPruningConfig" + "$ref": "#/components/schemas/_types.TokenPruningConfig" } }, "required": [ @@ -56483,7 +56499,7 @@ } ] }, - "_types.query_dsl.TokenPruningConfig": { + "_types.TokenPruningConfig": { "type": "object", "properties": { "tokens_freq_ratio_threshold": { @@ -56585,7 +56601,7 @@ "type": "string" }, "pruning_config": { - "$ref": "#/components/schemas/_types.query_dsl.TokenPruningConfig" + "$ref": "#/components/schemas/_types.TokenPruningConfig" } }, "required": [ @@ -56624,7 +56640,7 @@ ] }, "pruning_config": { - "$ref": "#/components/schemas/_types.query_dsl.TokenPruningConfig" + "$ref": "#/components/schemas/_types.TokenPruningConfig" } }, "required": [ @@ -63065,6 +63081,226 @@ } } }, + "cat._types.CatShardColumns": { + "oneOf": [ + { + "$ref": "#/components/schemas/cat._types.CatShardColumn" + }, + { + "type": "array", + "items": { + "$ref": "#/components/schemas/cat._types.CatShardColumn" + } + } + ] + }, + "cat._types.CatShardColumn": { + "anyOf": [ + { + "type": "string", + "enum": [ + "completion.size", + "cs", + "completionSize", + "dataset.size", + "dense_vector.value_count", + "dvc", + "denseVectorCount", + "docs", + "d", + "dc", + "fielddata.evictions", + "fe", + "fielddataEvictions", + "fielddata.memory_size", + "fm", + "fielddataMemory", + "flush.total", + "ft", + "flushTotal", + "flush.total_time", + "ftt", + "flushTotalTime", + "get.current", + "gc", + "getCurrent", + "get.exists_time", + "geti", + "getExistsTime", + "get.exists_total", + "geto", + "getExistsTotal", + "get.missing_time", + "gmti", + "getMissingTime", + "get.missing_total", + "gmto", + "getMissingTotal", + "get.time", + "gti", + "getTime", + "get.total", + "gto", + "getTotal", + "id", + "index", + "i", + "idx", + "indexing.delete_current", + "idc", + "indexingDeleteCurrent", + "indexing.delete_time", + "idti", + "indexingDeleteTime", + "indexing.delete_total", + "idto", + "indexingDeleteTotal", + "indexing.index_current", + "iic", + "indexingIndexCurrent", + "indexing.index_failed_due_to_version_conflict", + "iifvc", + "indexingIndexFailedDueToVersionConflict", + "indexing.index_failed", + "iif", + "indexingIndexFailed", + "indexing.index_time", + "iiti", + "indexingIndexTime", + "indexing.index_total", + "iito", + "indexingIndexTotal", + "ip", + "merges.current", + "mc", + "mergesCurrent", + "merges.current_docs", + "mcd", + "mergesCurrentDocs", + "merges.current_size", + "mcs", + "mergesCurrentSize", + "merges.total", + "mt", + "mergesTotal", + "merges.total_docs", + "mtd", + "mergesTotalDocs", + "merges.total_size", + "mts", + "mergesTotalSize", + "merges.total_time", + "mtt", + "mergesTotalTime", + "node", + "n", + "prirep", + "p", + "pr", + "primaryOrReplica", + "query_cache.evictions", + "qce", + "queryCacheEvictions", + "query_cache.memory_size", + "qcm", + "queryCacheMemory", + "recoverysource.type", + "rs", + "refresh.time", + "rti", + "refreshTime", + "refresh.total", + "rto", + "refreshTotal", + "search.fetch_current", + "sfc", + "searchFetchCurrent", + "search.fetch_time", + "sfti", + "searchFetchTime", + "search.fetch_total", + "sfto", + "searchFetchTotal", + "search.open_contexts", + "so", + "searchOpenContexts", + "search.query_current", + "sqc", + "searchQueryCurrent", + "search.query_time", + "sqti", + "searchQueryTime", + "search.query_total", + "sqto", + "searchQueryTotal", + "search.scroll_current", + "scc", + "searchScrollCurrent", + "search.scroll_time", + "scti", + "searchScrollTime", + "search.scroll_total", + "scto", + "searchScrollTotal", + "segments.count", + "sc", + "segmentsCount", + "segments.fixed_bitset_memory", + "sfbm", + "fixedBitsetMemory", + "segments.index_writer_memory", + "siwm", + "segmentsIndexWriterMemory", + "segments.memory", + "sm", + "segmentsMemory", + "segments.version_map_memory", + "svmm", + "segmentsVersionMapMemory", + "seq_no.global_checkpoint", + "sqg", + "globalCheckpoint", + "seq_no.local_checkpoint", + "sql", + "localCheckpoint", + "seq_no.max", + "sqm", + "maxSeqNo", + "shard", + "s", + "sh", + "dsparse_vector.value_count", + "svc", + "sparseVectorCount", + "state", + "st", + "store", + "sto", + "suggest.current", + "suc", + "suggestCurrent", + "suggest.time", + "suti", + "suggestTime", + "suggest.total", + "suto", + "suggestTotal", + "sync_id", + "unassigned.at", + "ua", + "unassigned.details", + "ud", + "unassigned.for", + "uf", + "unassigned.reason", + "ur" + ] + }, + { + "type": "string" + } + ] + }, "cat.shards.ShardsRecord": { "type": "object", "properties": { @@ -63656,6 +63892,69 @@ } } }, + "cat._types.CatThreadPoolColumns": { + "oneOf": [ + { + "$ref": "#/components/schemas/cat._types.CatThreadPoolColumn" + }, + { + "type": "array", + "items": { + "$ref": "#/components/schemas/cat._types.CatThreadPoolColumn" + } + } + ] + }, + "cat._types.CatThreadPoolColumn": { + "anyOf": [ + { + "type": "string", + "enum": [ + "active", + "a", + "completed", + "c", + "core", + "cr", + "ephemeral_id", + "eid", + "host", + "h", + "ip", + "i", + "keep_alive", + "k", + "largest", + "l", + "max", + "mx", + "name", + "node_id", + "id", + "node_name", + "pid", + "p", + "pool_size", + "psz", + "port", + "po", + "queue", + "q", + "queue_size", + "qs", + "rejected", + "r", + "size", + "sz", + "type", + "t" + ] + }, + { + "type": "string" + } + ] + }, "cat.thread_pool.ThreadPoolRecord": { "type": "object", "properties": { @@ -72528,6 +72827,9 @@ "enum": [ "sparse_vector" ] + }, + "index_options": { + "$ref": "#/components/schemas/_types.mapping.SparseVectorIndexOptions" } }, "required": [ @@ -72536,6 +72838,19 @@ } ] }, + "_types.mapping.SparseVectorIndexOptions": { + "type": "object", + "properties": { + "prune": { + "description": "Whether to perform pruning, omitting the non-significant tokens from the query to improve query performance.\nIf prune is true but the pruning_config is not specified, pruning will occur but default values will be used.\nDefault: false", + "x-state": "Generally available; Added in 8.19.0", + "type": "boolean" + }, + "pruning_config": { + "$ref": "#/components/schemas/_types.TokenPruningConfig" + } + } + }, "_types.mapping.CompletionProperty": { "allOf": [ { @@ -111039,14 +111354,14 @@ "description": "List of columns to appear in the response. Supports simple wildcards.", "deprecated": false, "schema": { - "$ref": "#/components/schemas/_types.Names" + "$ref": "#/components/schemas/cat._types.CatShardColumns" }, "style": "form" }, "cat.shards-s": { "in": "query", "name": "s", - "description": "List of columns that determine how the table should be sorted.\nSorting defaults to ascending and can be changed by setting `:asc`\nor `:desc` as a suffix to the column name.", + "description": "A comma-separated list of column names or aliases that determines the sort order.\nSorting defaults to ascending and can be changed by setting `:asc`\nor `:desc` as a suffix to the column name.", "deprecated": false, "schema": { "$ref": "#/components/schemas/_types.Names" @@ -111056,7 +111371,7 @@ "cat.shards-master_timeout": { "in": "query", "name": "master_timeout", - "description": "Period to wait for a connection to the master node.", + "description": "The period to wait for a connection to the master node.", "deprecated": false, "schema": { "$ref": "#/components/schemas/_types.Duration" @@ -111066,7 +111381,7 @@ "cat.shards-time": { "in": "query", "name": "time", - "description": "Unit used to display time values.", + "description": "The unit used to display time values.", "deprecated": false, "schema": { "$ref": "#/components/schemas/_types.TimeUnit" @@ -111202,14 +111517,14 @@ "description": "List of columns to appear in the response. Supports simple wildcards.", "deprecated": false, "schema": { - "$ref": "#/components/schemas/_types.Names" + "$ref": "#/components/schemas/cat._types.CatThreadPoolColumns" }, "style": "form" }, "cat.thread_pool-s": { "in": "query", "name": "s", - "description": "List of columns that determine how the table should be sorted.\nSorting defaults to ascending and can be changed by setting `:asc`\nor `:desc` as a suffix to the column name.", + "description": "A comma-separated list of column names or aliases that determines the sort order.\nSorting defaults to ascending and can be changed by setting `:asc`\nor `:desc` as a suffix to the column name.", "deprecated": false, "schema": { "$ref": "#/components/schemas/_types.Names" @@ -111239,7 +111554,7 @@ "cat.thread_pool-master_timeout": { "in": "query", "name": "master_timeout", - "description": "Period to wait for a connection to the master node.", + "description": "The period to wait for a connection to the master node.", "deprecated": false, "schema": { "$ref": "#/components/schemas/_types.Duration" @@ -123355,4 +123670,4 @@ } } } -} +} \ No newline at end of file diff --git a/output/openapi/elasticsearch-serverless-openapi.json b/output/openapi/elasticsearch-serverless-openapi.json index 5828df3c22..bd2c44e5da 100644 --- a/output/openapi/elasticsearch-serverless-openapi.json +++ b/output/openapi/elasticsearch-serverless-openapi.json @@ -24018,7 +24018,11 @@ "document" ], "summary": "Update a document", - "description": "Update a document by running a script or passing a partial document.\n\nIf the Elasticsearch security features are enabled, you must have the `index` or `write` index privilege for the target index or index alias.\n\nThe script can update, delete, or skip modifying the document.\nThe API also supports passing a partial document, which is merged into the existing document.\nTo fully replace an existing document, use the index API.\nThis operation:\n\n* Gets the document (collocated with the shard) from the index.\n* Runs the specified script.\n* Indexes the result.\n\nThe document must still be reindexed, but using this API removes some network roundtrips and reduces chances of version conflicts between the GET and the index operation.\n\nThe `_source` field must be enabled to use this API.\nIn addition to `_source`, you can access the following variables through the `ctx` map: `_index`, `_type`, `_id`, `_version`, `_routing`, and `_now` (the current timestamp).\n\n## Required authorization\n\n* Index privileges: `write`\n", + "description": "Update a document by running a script or passing a partial document.\n\nIf the Elasticsearch security features are enabled, you must have the `index` or `write` index privilege for the target index or index alias.\n\nThe script can update, delete, or skip modifying the document.\nThe API also supports passing a partial document, which is merged into the existing document.\nTo fully replace an existing document, use the index API.\nThis operation:\n\n* Gets the document (collocated with the shard) from the index.\n* Runs the specified script.\n* Indexes the result.\n\nThe document must still be reindexed, but using this API removes some network roundtrips and reduces chances of version conflicts between the GET and the index operation.\n\nThe `_source` field must be enabled to use this API.\nIn addition to `_source`, you can access the following variables through the `ctx` map: `_index`, `_type`, `_id`, `_version`, `_routing`, and `_now` (the current timestamp).\nFor usage examples such as partial updates, upserts, and scripted updates, see the External documentation.\n\n## Required authorization\n\n* Index privileges: `write`\n", + "externalDocs": { + "url": "https://www.elastic.co/docs/reference/elasticsearch/rest-apis/update-document", + "x-previousVersionUrl": "https://www.elastic.co/guide/en/elasticsearch/reference/8.18/docs-update.html" + }, "operationId": "update", "parameters": [ { @@ -24301,7 +24305,11 @@ "document" ], "summary": "Update documents", - "description": "Updates documents that match the specified query.\nIf no query is specified, performs an update on every document in the data stream or index without modifying the source, which is useful for picking up mapping changes.\n\nIf the Elasticsearch security features are enabled, you must have the following index privileges for the target data stream, index, or alias:\n\n* `read`\n* `index` or `write`\n\nYou can specify the query criteria in the request URI or the request body using the same syntax as the search API.\n\nWhen you submit an update by query request, Elasticsearch gets a snapshot of the data stream or index when it begins processing the request and updates matching documents using internal versioning.\nWhen the versions match, the document is updated and the version number is incremented.\nIf a document changes between the time that the snapshot is taken and the update operation is processed, it results in a version conflict and the operation fails.\nYou can opt to count version conflicts instead of halting and returning by setting `conflicts` to `proceed`.\nNote that if you opt to count version conflicts, the operation could attempt to update more documents from the source than `max_docs` until it has successfully updated `max_docs` documents or it has gone through every document in the source query.\n\nNOTE: Documents with a version equal to 0 cannot be updated using update by query because internal versioning does not support 0 as a valid version number.\n\nWhile processing an update by query request, Elasticsearch performs multiple search requests sequentially to find all of the matching documents.\nA bulk update request is performed for each batch of matching documents.\nAny query or update failures cause the update by query request to fail and the failures are shown in the response.\nAny update requests that completed successfully still stick, they are not rolled back.\n\n**Throttling update requests**\n\nTo control the rate at which update by query issues batches of update operations, you can set `requests_per_second` to any positive decimal number.\nThis pads each batch with a wait time to throttle the rate.\nSet `requests_per_second` to `-1` to turn off throttling.\n\nThrottling uses a wait time between batches so that the internal scroll requests can be given a timeout that takes the request padding into account.\nThe padding time is the difference between the batch size divided by the `requests_per_second` and the time spent writing.\nBy default the batch size is 1000, so if `requests_per_second` is set to `500`:\n\n```\ntarget_time = 1000 / 500 per second = 2 seconds\nwait_time = target_time - write_time = 2 seconds - .5 seconds = 1.5 seconds\n```\n\nSince the batch is issued as a single _bulk request, large batch sizes cause Elasticsearch to create many requests and wait before starting the next set.\nThis is \"bursty\" instead of \"smooth\".\n\n**Slicing**\n\nUpdate by query supports sliced scroll to parallelize the update process.\nThis can improve efficiency and provide a convenient way to break the request down into smaller parts.\n\nSetting `slices` to `auto` chooses a reasonable number for most data streams and indices.\nThis setting will use one slice per shard, up to a certain limit.\nIf there are multiple source data streams or indices, it will choose the number of slices based on the index or backing index with the smallest number of shards.\n\nAdding `slices` to `_update_by_query` just automates the manual process of creating sub-requests, which means it has some quirks:\n\n* You can see these requests in the tasks APIs. These sub-requests are \"child\" tasks of the task for the request with slices.\n* Fetching the status of the task for the request with `slices` only contains the status of completed slices.\n* These sub-requests are individually addressable for things like cancellation and rethrottling.\n* Rethrottling the request with `slices` will rethrottle the unfinished sub-request proportionally.\n* Canceling the request with slices will cancel each sub-request.\n* Due to the nature of slices each sub-request won't get a perfectly even portion of the documents. All documents will be addressed, but some slices may be larger than others. Expect larger slices to have a more even distribution.\n* Parameters like `requests_per_second` and `max_docs` on a request with slices are distributed proportionally to each sub-request. Combine that with the point above about distribution being uneven and you should conclude that using `max_docs` with `slices` might not result in exactly `max_docs` documents being updated.\n* Each sub-request gets a slightly different snapshot of the source data stream or index though these are all taken at approximately the same time.\n\nIf you're slicing manually or otherwise tuning automatic slicing, keep in mind that:\n\n* Query performance is most efficient when the number of slices is equal to the number of shards in the index or backing index. If that number is large (for example, 500), choose a lower number as too many slices hurts performance. Setting slices higher than the number of shards generally does not improve efficiency and adds overhead.\n* Update performance scales linearly across available resources with the number of slices.\n\nWhether query or update performance dominates the runtime depends on the documents being reindexed and cluster resources.\n\n**Update the document source**\n\nUpdate by query supports scripts to update the document source.\nAs with the update API, you can set `ctx.op` to change the operation that is performed.\n\nSet `ctx.op = \"noop\"` if your script decides that it doesn't have to make any changes.\nThe update by query operation skips updating the document and increments the `noop` counter.\n\nSet `ctx.op = \"delete\"` if your script decides that the document should be deleted.\nThe update by query operation deletes the document and increments the `deleted` counter.\n\nUpdate by query supports only `index`, `noop`, and `delete`.\nSetting `ctx.op` to anything else is an error.\nSetting any other field in `ctx` is an error.\nThis API enables you to only modify the source of matching documents; you cannot move them.\n\n## Required authorization\n\n* Index privileges: `read`,`write`\n", + "description": "Updates documents that match the specified query.\nIf no query is specified, performs an update on every document in the data stream or index without modifying the source, which is useful for picking up mapping changes.\n\nIf the Elasticsearch security features are enabled, you must have the following index privileges for the target data stream, index, or alias:\n\n* `read`\n* `index` or `write`\n\nYou can specify the query criteria in the request URI or the request body using the same syntax as the search API.\n\nWhen you submit an update by query request, Elasticsearch gets a snapshot of the data stream or index when it begins processing the request and updates matching documents using internal versioning.\nWhen the versions match, the document is updated and the version number is incremented.\nIf a document changes between the time that the snapshot is taken and the update operation is processed, it results in a version conflict and the operation fails.\nYou can opt to count version conflicts instead of halting and returning by setting `conflicts` to `proceed`.\nNote that if you opt to count version conflicts, the operation could attempt to update more documents from the source than `max_docs` until it has successfully updated `max_docs` documents or it has gone through every document in the source query.\n\nNOTE: Documents with a version equal to 0 cannot be updated using update by query because internal versioning does not support 0 as a valid version number.\n\nWhile processing an update by query request, Elasticsearch performs multiple search requests sequentially to find all of the matching documents.\nA bulk update request is performed for each batch of matching documents.\nAny query or update failures cause the update by query request to fail and the failures are shown in the response.\nAny update requests that completed successfully still stick, they are not rolled back.\n\n**Refreshing shards**\n\nSpecifying the `refresh` parameter refreshes all shards once the request completes.\nThis is different to the update API's `refresh` parameter, which causes only the shard\nthat received the request to be refreshed. Unlike the update API, it does not support\n`wait_for`.\n\n**Running update by query asynchronously**\n\nIf the request contains `wait_for_completion=false`, Elasticsearch\nperforms some preflight checks, launches the request, and returns a\n[task](https://www.elastic.co/docs/api/doc/elasticsearch/group/endpoint-tasks) you can use to cancel or get the status of the task.\nElasticsearch creates a record of this task as a document at `.tasks/task/${taskId}`.\n\n**Waiting for active shards**\n\n`wait_for_active_shards` controls how many copies of a shard must be active\nbefore proceeding with the request. See [`wait_for_active_shards`](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-create#operation-create-wait_for_active_shards)\nfor details. `timeout` controls how long each write request waits for unavailable\nshards to become available. Both work exactly the way they work in the\n[Bulk API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-bulk). Update by query uses scrolled searches, so you can also\nspecify the `scroll` parameter to control how long it keeps the search context\nalive, for example `?scroll=10m`. The default is 5 minutes.\n\n**Throttling update requests**\n\nTo control the rate at which update by query issues batches of update operations, you can set `requests_per_second` to any positive decimal number.\nThis pads each batch with a wait time to throttle the rate.\nSet `requests_per_second` to `-1` to turn off throttling.\n\nThrottling uses a wait time between batches so that the internal scroll requests can be given a timeout that takes the request padding into account.\nThe padding time is the difference between the batch size divided by the `requests_per_second` and the time spent writing.\nBy default the batch size is 1000, so if `requests_per_second` is set to `500`:\n\n```\ntarget_time = 1000 / 500 per second = 2 seconds\nwait_time = target_time - write_time = 2 seconds - .5 seconds = 1.5 seconds\n```\n\nSince the batch is issued as a single _bulk request, large batch sizes cause Elasticsearch to create many requests and wait before starting the next set.\nThis is \"bursty\" instead of \"smooth\".\n\n**Slicing**\n\nUpdate by query supports sliced scroll to parallelize the update process.\nThis can improve efficiency and provide a convenient way to break the request down into smaller parts.\n\nSetting `slices` to `auto` chooses a reasonable number for most data streams and indices.\nThis setting will use one slice per shard, up to a certain limit.\nIf there are multiple source data streams or indices, it will choose the number of slices based on the index or backing index with the smallest number of shards.\n\nAdding `slices` to `_update_by_query` just automates the manual process of creating sub-requests, which means it has some quirks:\n\n* You can see these requests in the tasks APIs. These sub-requests are \"child\" tasks of the task for the request with slices.\n* Fetching the status of the task for the request with `slices` only contains the status of completed slices.\n* These sub-requests are individually addressable for things like cancellation and rethrottling.\n* Rethrottling the request with `slices` will rethrottle the unfinished sub-request proportionally.\n* Canceling the request with slices will cancel each sub-request.\n* Due to the nature of slices each sub-request won't get a perfectly even portion of the documents. All documents will be addressed, but some slices may be larger than others. Expect larger slices to have a more even distribution.\n* Parameters like `requests_per_second` and `max_docs` on a request with slices are distributed proportionally to each sub-request. Combine that with the point above about distribution being uneven and you should conclude that using `max_docs` with `slices` might not result in exactly `max_docs` documents being updated.\n* Each sub-request gets a slightly different snapshot of the source data stream or index though these are all taken at approximately the same time.\n\nIf you're slicing manually or otherwise tuning automatic slicing, keep in mind that:\n\n* Query performance is most efficient when the number of slices is equal to the number of shards in the index or backing index. If that number is large (for example, 500), choose a lower number as too many slices hurts performance. Setting slices higher than the number of shards generally does not improve efficiency and adds overhead.\n* Update performance scales linearly across available resources with the number of slices.\n\nWhether query or update performance dominates the runtime depends on the documents being reindexed and cluster resources.\nRefer to the linked documentation for examples of how to update documents using the `_update_by_query` API:\n\n## Required authorization\n\n* Index privileges: `read`,`write`\n", + "externalDocs": { + "url": "https://www.elastic.co/docs/reference/elasticsearch/rest-apis/update-by-query-api", + "x-previousVersionUrl": "https://www.elastic.co/guide/en/elasticsearch/reference/8.18/docs-update-by-query.html" + }, "operationId": "update-by-query", "parameters": [ { @@ -35103,7 +35111,7 @@ "type": "boolean" }, "pruning_config": { - "$ref": "#/components/schemas/_types.query_dsl.TokenPruningConfig" + "$ref": "#/components/schemas/_types.TokenPruningConfig" } }, "required": [ @@ -35131,7 +35139,7 @@ } ] }, - "_types.query_dsl.TokenPruningConfig": { + "_types.TokenPruningConfig": { "type": "object", "properties": { "tokens_freq_ratio_threshold": { @@ -35233,7 +35241,7 @@ "type": "string" }, "pruning_config": { - "$ref": "#/components/schemas/_types.query_dsl.TokenPruningConfig" + "$ref": "#/components/schemas/_types.TokenPruningConfig" } }, "required": [ @@ -35272,7 +35280,7 @@ ] }, "pruning_config": { - "$ref": "#/components/schemas/_types.query_dsl.TokenPruningConfig" + "$ref": "#/components/schemas/_types.TokenPruningConfig" } }, "required": [ @@ -48221,6 +48229,9 @@ "enum": [ "sparse_vector" ] + }, + "index_options": { + "$ref": "#/components/schemas/_types.mapping.SparseVectorIndexOptions" } }, "required": [ @@ -48229,6 +48240,19 @@ } ] }, + "_types.mapping.SparseVectorIndexOptions": { + "type": "object", + "properties": { + "prune": { + "description": "Whether to perform pruning, omitting the non-significant tokens from the query to improve query performance.\nIf prune is true but the pruning_config is not specified, pruning will occur but default values will be used.\nDefault: false", + "x-state": "Generally available", + "type": "boolean" + }, + "pruning_config": { + "$ref": "#/components/schemas/_types.TokenPruningConfig" + } + } + }, "_types.mapping.CompletionProperty": { "allOf": [ { diff --git a/output/schema/schema.json b/output/schema/schema.json index 1ffea1f517..ebe0d172c1 100644 --- a/output/schema/schema.json +++ b/output/schema/schema.json @@ -17085,9 +17085,11 @@ "description": "", "version": "8.11.0" }, - "description": "Search rolled-up data.\nThe rollup search endpoint is needed because, internally, rolled-up documents utilize a different document structure than the original data.\nIt rewrites standard Query DSL into a format that matches the rollup documents then takes the response and rewrites it back to what a client would expect given the original query.\n\nThe request body supports a subset of features from the regular search API.\nThe following functionality is not available:\n\n`size`: Because rollups work on pre-aggregated data, no search hits can be returned and so size must be set to zero or omitted entirely.\n`highlighter`, `suggestors`, `post_filter`, `profile`, `explain`: These are similarly disallowed.\n\n**Searching both historical rollup and non-rollup data**\n\nThe rollup search API has the capability to search across both \"live\" non-rollup data and the aggregated rollup data.\nThis is done by simply adding the live indices to the URI. For example:\n\n```\nGET sensor-1,sensor_rollup/_rollup_search\n{\n \"size\": 0,\n \"aggregations\": {\n \"max_temperature\": {\n \"max\": {\n \"field\": \"temperature\"\n }\n }\n }\n}\n```\n\nThe rollup search endpoint does two things when the search runs:\n\n* The original request is sent to the non-rollup index unaltered.\n* A rewritten version of the original request is sent to the rollup index.\n\nWhen the two responses are received, the endpoint rewrites the rollup response and merges the two together.\nDuring the merging process, if there is any overlap in buckets between the two responses, the buckets from the non-rollup index are used.", + "description": "Search rolled-up data.\nThe rollup search endpoint is needed because, internally, rolled-up documents utilize a different document structure than the original data.\nIt rewrites standard Query DSL into a format that matches the rollup documents then takes the response and rewrites it back to what a client would expect given the original query.\n\nThe request body supports a subset of features from the regular search API.\nThe following functionality is not available:\n\n`size`: Because rollups work on pre-aggregated data, no search hits can be returned and so size must be set to zero or omitted entirely.\n`highlighter`, `suggestors`, `post_filter`, `profile`, `explain`: These are similarly disallowed.\n\nFor more detailed examples of using the rollup search API, including querying rolled-up data only or combining rolled-up and live data, refer to the External documentation.", "docId": "rollup-search", "docUrl": "https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-rollup-rollup-search", + "extDocId": "rollup-examples", + "extDocUrl": "https://www.elastic.co/docs/manage-data/lifecycle/rollup/getting-started-api#historical-only-search-example", "extPreviousVersionDocUrl": "https://www.elastic.co/guide/en/elasticsearch/reference/8.18/rollup-search.html", "name": "rollup.rollup_search", "request": { @@ -23669,10 +23671,12 @@ "stability": "stable" } }, - "description": "Update a document.\n\nUpdate a document by running a script or passing a partial document.\n\nIf the Elasticsearch security features are enabled, you must have the `index` or `write` index privilege for the target index or index alias.\n\nThe script can update, delete, or skip modifying the document.\nThe API also supports passing a partial document, which is merged into the existing document.\nTo fully replace an existing document, use the index API.\nThis operation:\n\n* Gets the document (collocated with the shard) from the index.\n* Runs the specified script.\n* Indexes the result.\n\nThe document must still be reindexed, but using this API removes some network roundtrips and reduces chances of version conflicts between the GET and the index operation.\n\nThe `_source` field must be enabled to use this API.\nIn addition to `_source`, you can access the following variables through the `ctx` map: `_index`, `_type`, `_id`, `_version`, `_routing`, and `_now` (the current timestamp).", + "description": "Update a document.\n\nUpdate a document by running a script or passing a partial document.\n\nIf the Elasticsearch security features are enabled, you must have the `index` or `write` index privilege for the target index or index alias.\n\nThe script can update, delete, or skip modifying the document.\nThe API also supports passing a partial document, which is merged into the existing document.\nTo fully replace an existing document, use the index API.\nThis operation:\n\n* Gets the document (collocated with the shard) from the index.\n* Runs the specified script.\n* Indexes the result.\n\nThe document must still be reindexed, but using this API removes some network roundtrips and reduces chances of version conflicts between the GET and the index operation.\n\nThe `_source` field must be enabled to use this API.\nIn addition to `_source`, you can access the following variables through the `ctx` map: `_index`, `_type`, `_id`, `_version`, `_routing`, and `_now` (the current timestamp).\nFor usage examples such as partial updates, upserts, and scripted updates, see the External documentation.", "docId": "docs-update", "docTag": "document", "docUrl": "https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-update", + "extDocId": "update-document", + "extDocUrl": "https://www.elastic.co/docs/reference/elasticsearch/rest-apis/update-document", "extPreviousVersionDocUrl": "https://www.elastic.co/guide/en/elasticsearch/reference/8.18/docs-update.html", "name": "update", "privileges": { @@ -23715,10 +23719,12 @@ "stability": "stable" } }, - "description": "Update documents.\nUpdates documents that match the specified query.\nIf no query is specified, performs an update on every document in the data stream or index without modifying the source, which is useful for picking up mapping changes.\n\nIf the Elasticsearch security features are enabled, you must have the following index privileges for the target data stream, index, or alias:\n\n* `read`\n* `index` or `write`\n\nYou can specify the query criteria in the request URI or the request body using the same syntax as the search API.\n\nWhen you submit an update by query request, Elasticsearch gets a snapshot of the data stream or index when it begins processing the request and updates matching documents using internal versioning.\nWhen the versions match, the document is updated and the version number is incremented.\nIf a document changes between the time that the snapshot is taken and the update operation is processed, it results in a version conflict and the operation fails.\nYou can opt to count version conflicts instead of halting and returning by setting `conflicts` to `proceed`.\nNote that if you opt to count version conflicts, the operation could attempt to update more documents from the source than `max_docs` until it has successfully updated `max_docs` documents or it has gone through every document in the source query.\n\nNOTE: Documents with a version equal to 0 cannot be updated using update by query because internal versioning does not support 0 as a valid version number.\n\nWhile processing an update by query request, Elasticsearch performs multiple search requests sequentially to find all of the matching documents.\nA bulk update request is performed for each batch of matching documents.\nAny query or update failures cause the update by query request to fail and the failures are shown in the response.\nAny update requests that completed successfully still stick, they are not rolled back.\n\n**Throttling update requests**\n\nTo control the rate at which update by query issues batches of update operations, you can set `requests_per_second` to any positive decimal number.\nThis pads each batch with a wait time to throttle the rate.\nSet `requests_per_second` to `-1` to turn off throttling.\n\nThrottling uses a wait time between batches so that the internal scroll requests can be given a timeout that takes the request padding into account.\nThe padding time is the difference between the batch size divided by the `requests_per_second` and the time spent writing.\nBy default the batch size is 1000, so if `requests_per_second` is set to `500`:\n\n```\ntarget_time = 1000 / 500 per second = 2 seconds\nwait_time = target_time - write_time = 2 seconds - .5 seconds = 1.5 seconds\n```\n\nSince the batch is issued as a single _bulk request, large batch sizes cause Elasticsearch to create many requests and wait before starting the next set.\nThis is \"bursty\" instead of \"smooth\".\n\n**Slicing**\n\nUpdate by query supports sliced scroll to parallelize the update process.\nThis can improve efficiency and provide a convenient way to break the request down into smaller parts.\n\nSetting `slices` to `auto` chooses a reasonable number for most data streams and indices.\nThis setting will use one slice per shard, up to a certain limit.\nIf there are multiple source data streams or indices, it will choose the number of slices based on the index or backing index with the smallest number of shards.\n\nAdding `slices` to `_update_by_query` just automates the manual process of creating sub-requests, which means it has some quirks:\n\n* You can see these requests in the tasks APIs. These sub-requests are \"child\" tasks of the task for the request with slices.\n* Fetching the status of the task for the request with `slices` only contains the status of completed slices.\n* These sub-requests are individually addressable for things like cancellation and rethrottling.\n* Rethrottling the request with `slices` will rethrottle the unfinished sub-request proportionally.\n* Canceling the request with slices will cancel each sub-request.\n* Due to the nature of slices each sub-request won't get a perfectly even portion of the documents. All documents will be addressed, but some slices may be larger than others. Expect larger slices to have a more even distribution.\n* Parameters like `requests_per_second` and `max_docs` on a request with slices are distributed proportionally to each sub-request. Combine that with the point above about distribution being uneven and you should conclude that using `max_docs` with `slices` might not result in exactly `max_docs` documents being updated.\n* Each sub-request gets a slightly different snapshot of the source data stream or index though these are all taken at approximately the same time.\n\nIf you're slicing manually or otherwise tuning automatic slicing, keep in mind that:\n\n* Query performance is most efficient when the number of slices is equal to the number of shards in the index or backing index. If that number is large (for example, 500), choose a lower number as too many slices hurts performance. Setting slices higher than the number of shards generally does not improve efficiency and adds overhead.\n* Update performance scales linearly across available resources with the number of slices.\n\nWhether query or update performance dominates the runtime depends on the documents being reindexed and cluster resources.\n\n**Update the document source**\n\nUpdate by query supports scripts to update the document source.\nAs with the update API, you can set `ctx.op` to change the operation that is performed.\n\nSet `ctx.op = \"noop\"` if your script decides that it doesn't have to make any changes.\nThe update by query operation skips updating the document and increments the `noop` counter.\n\nSet `ctx.op = \"delete\"` if your script decides that the document should be deleted.\nThe update by query operation deletes the document and increments the `deleted` counter.\n\nUpdate by query supports only `index`, `noop`, and `delete`.\nSetting `ctx.op` to anything else is an error.\nSetting any other field in `ctx` is an error.\nThis API enables you to only modify the source of matching documents; you cannot move them.", + "description": "Update documents.\nUpdates documents that match the specified query.\nIf no query is specified, performs an update on every document in the data stream or index without modifying the source, which is useful for picking up mapping changes.\n\nIf the Elasticsearch security features are enabled, you must have the following index privileges for the target data stream, index, or alias:\n\n* `read`\n* `index` or `write`\n\nYou can specify the query criteria in the request URI or the request body using the same syntax as the search API.\n\nWhen you submit an update by query request, Elasticsearch gets a snapshot of the data stream or index when it begins processing the request and updates matching documents using internal versioning.\nWhen the versions match, the document is updated and the version number is incremented.\nIf a document changes between the time that the snapshot is taken and the update operation is processed, it results in a version conflict and the operation fails.\nYou can opt to count version conflicts instead of halting and returning by setting `conflicts` to `proceed`.\nNote that if you opt to count version conflicts, the operation could attempt to update more documents from the source than `max_docs` until it has successfully updated `max_docs` documents or it has gone through every document in the source query.\n\nNOTE: Documents with a version equal to 0 cannot be updated using update by query because internal versioning does not support 0 as a valid version number.\n\nWhile processing an update by query request, Elasticsearch performs multiple search requests sequentially to find all of the matching documents.\nA bulk update request is performed for each batch of matching documents.\nAny query or update failures cause the update by query request to fail and the failures are shown in the response.\nAny update requests that completed successfully still stick, they are not rolled back.\n\n**Refreshing shards**\n\nSpecifying the `refresh` parameter refreshes all shards once the request completes.\nThis is different to the update API's `refresh` parameter, which causes only the shard\nthat received the request to be refreshed. Unlike the update API, it does not support\n`wait_for`.\n\n**Running update by query asynchronously**\n\nIf the request contains `wait_for_completion=false`, Elasticsearch\nperforms some preflight checks, launches the request, and returns a\n[task](https://www.elastic.co/docs/api/doc/elasticsearch/group/endpoint-tasks) you can use to cancel or get the status of the task.\nElasticsearch creates a record of this task as a document at `.tasks/task/${taskId}`.\n\n**Waiting for active shards**\n\n`wait_for_active_shards` controls how many copies of a shard must be active\nbefore proceeding with the request. See [`wait_for_active_shards`](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-create#operation-create-wait_for_active_shards)\nfor details. `timeout` controls how long each write request waits for unavailable\nshards to become available. Both work exactly the way they work in the\n[Bulk API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-bulk). Update by query uses scrolled searches, so you can also\nspecify the `scroll` parameter to control how long it keeps the search context\nalive, for example `?scroll=10m`. The default is 5 minutes.\n\n**Throttling update requests**\n\nTo control the rate at which update by query issues batches of update operations, you can set `requests_per_second` to any positive decimal number.\nThis pads each batch with a wait time to throttle the rate.\nSet `requests_per_second` to `-1` to turn off throttling.\n\nThrottling uses a wait time between batches so that the internal scroll requests can be given a timeout that takes the request padding into account.\nThe padding time is the difference between the batch size divided by the `requests_per_second` and the time spent writing.\nBy default the batch size is 1000, so if `requests_per_second` is set to `500`:\n\n```\ntarget_time = 1000 / 500 per second = 2 seconds\nwait_time = target_time - write_time = 2 seconds - .5 seconds = 1.5 seconds\n```\n\nSince the batch is issued as a single _bulk request, large batch sizes cause Elasticsearch to create many requests and wait before starting the next set.\nThis is \"bursty\" instead of \"smooth\".\n\n**Slicing**\n\nUpdate by query supports sliced scroll to parallelize the update process.\nThis can improve efficiency and provide a convenient way to break the request down into smaller parts.\n\nSetting `slices` to `auto` chooses a reasonable number for most data streams and indices.\nThis setting will use one slice per shard, up to a certain limit.\nIf there are multiple source data streams or indices, it will choose the number of slices based on the index or backing index with the smallest number of shards.\n\nAdding `slices` to `_update_by_query` just automates the manual process of creating sub-requests, which means it has some quirks:\n\n* You can see these requests in the tasks APIs. These sub-requests are \"child\" tasks of the task for the request with slices.\n* Fetching the status of the task for the request with `slices` only contains the status of completed slices.\n* These sub-requests are individually addressable for things like cancellation and rethrottling.\n* Rethrottling the request with `slices` will rethrottle the unfinished sub-request proportionally.\n* Canceling the request with slices will cancel each sub-request.\n* Due to the nature of slices each sub-request won't get a perfectly even portion of the documents. All documents will be addressed, but some slices may be larger than others. Expect larger slices to have a more even distribution.\n* Parameters like `requests_per_second` and `max_docs` on a request with slices are distributed proportionally to each sub-request. Combine that with the point above about distribution being uneven and you should conclude that using `max_docs` with `slices` might not result in exactly `max_docs` documents being updated.\n* Each sub-request gets a slightly different snapshot of the source data stream or index though these are all taken at approximately the same time.\n\nIf you're slicing manually or otherwise tuning automatic slicing, keep in mind that:\n\n* Query performance is most efficient when the number of slices is equal to the number of shards in the index or backing index. If that number is large (for example, 500), choose a lower number as too many slices hurts performance. Setting slices higher than the number of shards generally does not improve efficiency and adds overhead.\n* Update performance scales linearly across available resources with the number of slices.\n\nWhether query or update performance dominates the runtime depends on the documents being reindexed and cluster resources.\nRefer to the linked documentation for examples of how to update documents using the `_update_by_query` API:", "docId": "docs-update-by-query", "docTag": "document", "docUrl": "https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-update-by-query", + "extDocId": "update-by-query", + "extDocUrl": "https://www.elastic.co/docs/reference/elasticsearch/rest-apis/update-by-query-api", "extPreviousVersionDocUrl": "https://www.elastic.co/guide/en/elasticsearch/reference/8.18/docs-update-by-query.html", "name": "update_by_query", "privileges": { @@ -47687,7 +47693,7 @@ } ] }, - "description": "Update a document.\n\nUpdate a document by running a script or passing a partial document.\n\nIf the Elasticsearch security features are enabled, you must have the `index` or `write` index privilege for the target index or index alias.\n\nThe script can update, delete, or skip modifying the document.\nThe API also supports passing a partial document, which is merged into the existing document.\nTo fully replace an existing document, use the index API.\nThis operation:\n\n* Gets the document (collocated with the shard) from the index.\n* Runs the specified script.\n* Indexes the result.\n\nThe document must still be reindexed, but using this API removes some network roundtrips and reduces chances of version conflicts between the GET and the index operation.\n\nThe `_source` field must be enabled to use this API.\nIn addition to `_source`, you can access the following variables through the `ctx` map: `_index`, `_type`, `_id`, `_version`, `_routing`, and `_now` (the current timestamp).", + "description": "Update a document.\n\nUpdate a document by running a script or passing a partial document.\n\nIf the Elasticsearch security features are enabled, you must have the `index` or `write` index privilege for the target index or index alias.\n\nThe script can update, delete, or skip modifying the document.\nThe API also supports passing a partial document, which is merged into the existing document.\nTo fully replace an existing document, use the index API.\nThis operation:\n\n* Gets the document (collocated with the shard) from the index.\n* Runs the specified script.\n* Indexes the result.\n\nThe document must still be reindexed, but using this API removes some network roundtrips and reduces chances of version conflicts between the GET and the index operation.\n\nThe `_source` field must be enabled to use this API.\nIn addition to `_source`, you can access the following variables through the `ctx` map: `_index`, `_type`, `_id`, `_version`, `_routing`, and `_now` (the current timestamp).\nFor usage examples such as partial updates, upserts, and scripted updates, see the External documentation.", "examples": { "UpdateRequestExample1": { "alternatives": [ @@ -48258,7 +48264,7 @@ } } ], - "specLocation": "_global/update/UpdateRequest.ts#L38-L194" + "specLocation": "_global/update/UpdateRequest.ts#L38-L196" }, { "kind": "response", @@ -48414,7 +48420,7 @@ } ] }, - "description": "Update documents.\nUpdates documents that match the specified query.\nIf no query is specified, performs an update on every document in the data stream or index without modifying the source, which is useful for picking up mapping changes.\n\nIf the Elasticsearch security features are enabled, you must have the following index privileges for the target data stream, index, or alias:\n\n* `read`\n* `index` or `write`\n\nYou can specify the query criteria in the request URI or the request body using the same syntax as the search API.\n\nWhen you submit an update by query request, Elasticsearch gets a snapshot of the data stream or index when it begins processing the request and updates matching documents using internal versioning.\nWhen the versions match, the document is updated and the version number is incremented.\nIf a document changes between the time that the snapshot is taken and the update operation is processed, it results in a version conflict and the operation fails.\nYou can opt to count version conflicts instead of halting and returning by setting `conflicts` to `proceed`.\nNote that if you opt to count version conflicts, the operation could attempt to update more documents from the source than `max_docs` until it has successfully updated `max_docs` documents or it has gone through every document in the source query.\n\nNOTE: Documents with a version equal to 0 cannot be updated using update by query because internal versioning does not support 0 as a valid version number.\n\nWhile processing an update by query request, Elasticsearch performs multiple search requests sequentially to find all of the matching documents.\nA bulk update request is performed for each batch of matching documents.\nAny query or update failures cause the update by query request to fail and the failures are shown in the response.\nAny update requests that completed successfully still stick, they are not rolled back.\n\n**Throttling update requests**\n\nTo control the rate at which update by query issues batches of update operations, you can set `requests_per_second` to any positive decimal number.\nThis pads each batch with a wait time to throttle the rate.\nSet `requests_per_second` to `-1` to turn off throttling.\n\nThrottling uses a wait time between batches so that the internal scroll requests can be given a timeout that takes the request padding into account.\nThe padding time is the difference between the batch size divided by the `requests_per_second` and the time spent writing.\nBy default the batch size is 1000, so if `requests_per_second` is set to `500`:\n\n```\ntarget_time = 1000 / 500 per second = 2 seconds\nwait_time = target_time - write_time = 2 seconds - .5 seconds = 1.5 seconds\n```\n\nSince the batch is issued as a single _bulk request, large batch sizes cause Elasticsearch to create many requests and wait before starting the next set.\nThis is \"bursty\" instead of \"smooth\".\n\n**Slicing**\n\nUpdate by query supports sliced scroll to parallelize the update process.\nThis can improve efficiency and provide a convenient way to break the request down into smaller parts.\n\nSetting `slices` to `auto` chooses a reasonable number for most data streams and indices.\nThis setting will use one slice per shard, up to a certain limit.\nIf there are multiple source data streams or indices, it will choose the number of slices based on the index or backing index with the smallest number of shards.\n\nAdding `slices` to `_update_by_query` just automates the manual process of creating sub-requests, which means it has some quirks:\n\n* You can see these requests in the tasks APIs. These sub-requests are \"child\" tasks of the task for the request with slices.\n* Fetching the status of the task for the request with `slices` only contains the status of completed slices.\n* These sub-requests are individually addressable for things like cancellation and rethrottling.\n* Rethrottling the request with `slices` will rethrottle the unfinished sub-request proportionally.\n* Canceling the request with slices will cancel each sub-request.\n* Due to the nature of slices each sub-request won't get a perfectly even portion of the documents. All documents will be addressed, but some slices may be larger than others. Expect larger slices to have a more even distribution.\n* Parameters like `requests_per_second` and `max_docs` on a request with slices are distributed proportionally to each sub-request. Combine that with the point above about distribution being uneven and you should conclude that using `max_docs` with `slices` might not result in exactly `max_docs` documents being updated.\n* Each sub-request gets a slightly different snapshot of the source data stream or index though these are all taken at approximately the same time.\n\nIf you're slicing manually or otherwise tuning automatic slicing, keep in mind that:\n\n* Query performance is most efficient when the number of slices is equal to the number of shards in the index or backing index. If that number is large (for example, 500), choose a lower number as too many slices hurts performance. Setting slices higher than the number of shards generally does not improve efficiency and adds overhead.\n* Update performance scales linearly across available resources with the number of slices.\n\nWhether query or update performance dominates the runtime depends on the documents being reindexed and cluster resources.\n\n**Update the document source**\n\nUpdate by query supports scripts to update the document source.\nAs with the update API, you can set `ctx.op` to change the operation that is performed.\n\nSet `ctx.op = \"noop\"` if your script decides that it doesn't have to make any changes.\nThe update by query operation skips updating the document and increments the `noop` counter.\n\nSet `ctx.op = \"delete\"` if your script decides that the document should be deleted.\nThe update by query operation deletes the document and increments the `deleted` counter.\n\nUpdate by query supports only `index`, `noop`, and `delete`.\nSetting `ctx.op` to anything else is an error.\nSetting any other field in `ctx` is an error.\nThis API enables you to only modify the source of matching documents; you cannot move them.", + "description": "Update documents.\nUpdates documents that match the specified query.\nIf no query is specified, performs an update on every document in the data stream or index without modifying the source, which is useful for picking up mapping changes.\n\nIf the Elasticsearch security features are enabled, you must have the following index privileges for the target data stream, index, or alias:\n\n* `read`\n* `index` or `write`\n\nYou can specify the query criteria in the request URI or the request body using the same syntax as the search API.\n\nWhen you submit an update by query request, Elasticsearch gets a snapshot of the data stream or index when it begins processing the request and updates matching documents using internal versioning.\nWhen the versions match, the document is updated and the version number is incremented.\nIf a document changes between the time that the snapshot is taken and the update operation is processed, it results in a version conflict and the operation fails.\nYou can opt to count version conflicts instead of halting and returning by setting `conflicts` to `proceed`.\nNote that if you opt to count version conflicts, the operation could attempt to update more documents from the source than `max_docs` until it has successfully updated `max_docs` documents or it has gone through every document in the source query.\n\nNOTE: Documents with a version equal to 0 cannot be updated using update by query because internal versioning does not support 0 as a valid version number.\n\nWhile processing an update by query request, Elasticsearch performs multiple search requests sequentially to find all of the matching documents.\nA bulk update request is performed for each batch of matching documents.\nAny query or update failures cause the update by query request to fail and the failures are shown in the response.\nAny update requests that completed successfully still stick, they are not rolled back.\n\n**Refreshing shards**\n\nSpecifying the `refresh` parameter refreshes all shards once the request completes.\nThis is different to the update API's `refresh` parameter, which causes only the shard\nthat received the request to be refreshed. Unlike the update API, it does not support\n`wait_for`.\n\n**Running update by query asynchronously**\n\nIf the request contains `wait_for_completion=false`, Elasticsearch\nperforms some preflight checks, launches the request, and returns a\n[task](https://www.elastic.co/docs/api/doc/elasticsearch/group/endpoint-tasks) you can use to cancel or get the status of the task.\nElasticsearch creates a record of this task as a document at `.tasks/task/${taskId}`.\n\n**Waiting for active shards**\n\n`wait_for_active_shards` controls how many copies of a shard must be active\nbefore proceeding with the request. See [`wait_for_active_shards`](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-create#operation-create-wait_for_active_shards)\nfor details. `timeout` controls how long each write request waits for unavailable\nshards to become available. Both work exactly the way they work in the\n[Bulk API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-bulk). Update by query uses scrolled searches, so you can also\nspecify the `scroll` parameter to control how long it keeps the search context\nalive, for example `?scroll=10m`. The default is 5 minutes.\n\n**Throttling update requests**\n\nTo control the rate at which update by query issues batches of update operations, you can set `requests_per_second` to any positive decimal number.\nThis pads each batch with a wait time to throttle the rate.\nSet `requests_per_second` to `-1` to turn off throttling.\n\nThrottling uses a wait time between batches so that the internal scroll requests can be given a timeout that takes the request padding into account.\nThe padding time is the difference between the batch size divided by the `requests_per_second` and the time spent writing.\nBy default the batch size is 1000, so if `requests_per_second` is set to `500`:\n\n```\ntarget_time = 1000 / 500 per second = 2 seconds\nwait_time = target_time - write_time = 2 seconds - .5 seconds = 1.5 seconds\n```\n\nSince the batch is issued as a single _bulk request, large batch sizes cause Elasticsearch to create many requests and wait before starting the next set.\nThis is \"bursty\" instead of \"smooth\".\n\n**Slicing**\n\nUpdate by query supports sliced scroll to parallelize the update process.\nThis can improve efficiency and provide a convenient way to break the request down into smaller parts.\n\nSetting `slices` to `auto` chooses a reasonable number for most data streams and indices.\nThis setting will use one slice per shard, up to a certain limit.\nIf there are multiple source data streams or indices, it will choose the number of slices based on the index or backing index with the smallest number of shards.\n\nAdding `slices` to `_update_by_query` just automates the manual process of creating sub-requests, which means it has some quirks:\n\n* You can see these requests in the tasks APIs. These sub-requests are \"child\" tasks of the task for the request with slices.\n* Fetching the status of the task for the request with `slices` only contains the status of completed slices.\n* These sub-requests are individually addressable for things like cancellation and rethrottling.\n* Rethrottling the request with `slices` will rethrottle the unfinished sub-request proportionally.\n* Canceling the request with slices will cancel each sub-request.\n* Due to the nature of slices each sub-request won't get a perfectly even portion of the documents. All documents will be addressed, but some slices may be larger than others. Expect larger slices to have a more even distribution.\n* Parameters like `requests_per_second` and `max_docs` on a request with slices are distributed proportionally to each sub-request. Combine that with the point above about distribution being uneven and you should conclude that using `max_docs` with `slices` might not result in exactly `max_docs` documents being updated.\n* Each sub-request gets a slightly different snapshot of the source data stream or index though these are all taken at approximately the same time.\n\nIf you're slicing manually or otherwise tuning automatic slicing, keep in mind that:\n\n* Query performance is most efficient when the number of slices is equal to the number of shards in the index or backing index. If that number is large (for example, 500), choose a lower number as too many slices hurts performance. Setting slices higher than the number of shards generally does not improve efficiency and adds overhead.\n* Update performance scales linearly across available resources with the number of slices.\n\nWhether query or update performance dominates the runtime depends on the documents being reindexed and cluster resources.\nRefer to the linked documentation for examples of how to update documents using the `_update_by_query` API:", "examples": { "UpdateByQueryRequestExample1": { "alternatives": [ @@ -48965,7 +48971,7 @@ } } ], - "specLocation": "_global/update_by_query/UpdateByQueryRequest.ts#L37-L339" + "specLocation": "_global/update_by_query/UpdateByQueryRequest.ts#L37-L349" }, { "kind": "response", @@ -57621,6 +57627,55 @@ } } }, + { + "kind": "interface", + "name": { + "name": "TokenPruningConfig", + "namespace": "_types" + }, + "properties": [ + { + "description": "Tokens whose frequency is more than this threshold times the average frequency of all tokens in the specified field are considered outliers and pruned.", + "name": "tokens_freq_ratio_threshold", + "required": false, + "serverDefault": 5, + "type": { + "kind": "instance_of", + "type": { + "name": "integer", + "namespace": "_types" + } + } + }, + { + "description": "Tokens whose weight is less than this threshold are considered nonsignificant and pruned.", + "name": "tokens_weight_threshold", + "required": false, + "serverDefault": 0.4, + "type": { + "kind": "instance_of", + "type": { + "name": "float", + "namespace": "_types" + } + } + }, + { + "description": "Whether to only score pruned tokens, vs only scoring kept tokens.", + "name": "only_score_pruned_tokens", + "required": false, + "serverDefault": false, + "type": { + "kind": "instance_of", + "type": { + "name": "boolean", + "namespace": "_builtins" + } + } + } + ], + "specLocation": "_types/TokenPruningConfig.ts#L22-L35" + }, { "kind": "interface", "name": { @@ -81264,7 +81319,7 @@ } } ], - "specLocation": "_types/mapping/core.ts#L55-L57" + "specLocation": "_types/mapping/core.ts#L56-L58" }, { "kind": "interface", @@ -81385,7 +81440,7 @@ } } ], - "specLocation": "_types/mapping/core.ts#L59-L74" + "specLocation": "_types/mapping/core.ts#L60-L75" }, { "kind": "interface", @@ -81420,7 +81475,7 @@ } } ], - "specLocation": "_types/mapping/core.ts#L186-L189" + "specLocation": "_types/mapping/core.ts#L187-L190" }, { "kind": "interface", @@ -81685,7 +81740,7 @@ } } ], - "specLocation": "_types/mapping/core.ts#L46-L49" + "specLocation": "_types/mapping/core.ts#L47-L50" }, { "kind": "interface", @@ -81853,7 +81908,7 @@ } } ], - "specLocation": "_types/mapping/core.ts#L90-L100" + "specLocation": "_types/mapping/core.ts#L91-L101" }, { "kind": "interface", @@ -81987,7 +82042,7 @@ } } ], - "specLocation": "_types/mapping/core.ts#L76-L88" + "specLocation": "_types/mapping/core.ts#L77-L89" }, { "kind": "interface", @@ -82319,7 +82374,7 @@ } } ], - "specLocation": "_types/mapping/core.ts#L51-L53" + "specLocation": "_types/mapping/core.ts#L52-L54" }, { "kind": "interface", @@ -82354,7 +82409,7 @@ } } ], - "specLocation": "_types/mapping/core.ts#L166-L169" + "specLocation": "_types/mapping/core.ts#L167-L170" }, { "kind": "interface", @@ -82679,7 +82734,7 @@ } } ], - "specLocation": "_types/mapping/core.ts#L345-L376" + "specLocation": "_types/mapping/core.ts#L353-L384" }, { "kind": "interface", @@ -83313,7 +83368,7 @@ } } ], - "specLocation": "_types/mapping/core.ts#L156-L159" + "specLocation": "_types/mapping/core.ts#L157-L160" }, { "kind": "interface", @@ -83627,7 +83682,7 @@ } } ], - "specLocation": "_types/mapping/core.ts#L161-L164" + "specLocation": "_types/mapping/core.ts#L162-L165" }, { "kind": "interface", @@ -83907,7 +83962,7 @@ "name": "IndexOptions", "namespace": "_types.mapping" }, - "specLocation": "_types/mapping/core.ts#L301-L306" + "specLocation": "_types/mapping/core.ts#L309-L314" }, { "kind": "interface", @@ -83942,7 +83997,7 @@ } } ], - "specLocation": "_types/mapping/core.ts#L171-L174" + "specLocation": "_types/mapping/core.ts#L172-L175" }, { "kind": "interface", @@ -84172,7 +84227,7 @@ } } ], - "specLocation": "_types/mapping/core.ts#L102-L106" + "specLocation": "_types/mapping/core.ts#L103-L107" }, { "kind": "interface", @@ -84349,7 +84404,7 @@ } } ], - "specLocation": "_types/mapping/core.ts#L108-L127" + "specLocation": "_types/mapping/core.ts#L109-L128" }, { "kind": "interface", @@ -84384,7 +84439,7 @@ } } ], - "specLocation": "_types/mapping/core.ts#L176-L179" + "specLocation": "_types/mapping/core.ts#L177-L180" }, { "kind": "interface", @@ -84489,7 +84544,7 @@ } } ], - "specLocation": "_types/mapping/core.ts#L274-L299" + "specLocation": "_types/mapping/core.ts#L282-L307" }, { "kind": "enum", @@ -84709,7 +84764,7 @@ } } ], - "specLocation": "_types/mapping/core.ts#L129-L149" + "specLocation": "_types/mapping/core.ts#L130-L150" }, { "kind": "interface", @@ -84771,7 +84826,7 @@ "name": "OnScriptError", "namespace": "_types.mapping" }, - "specLocation": "_types/mapping/core.ts#L151-L154" + "specLocation": "_types/mapping/core.ts#L152-L155" }, { "kind": "interface", @@ -84852,7 +84907,7 @@ } } ], - "specLocation": "_types/mapping/core.ts#L202-L204" + "specLocation": "_types/mapping/core.ts#L203-L205" }, { "kind": "interface", @@ -85488,7 +85543,7 @@ } } ], - "specLocation": "_types/mapping/core.ts#L206-L209" + "specLocation": "_types/mapping/core.ts#L207-L210" }, { "kind": "interface", @@ -85523,7 +85578,7 @@ } } ], - "specLocation": "_types/mapping/core.ts#L211-L214" + "specLocation": "_types/mapping/core.ts#L212-L215" }, { "kind": "enum", @@ -85542,7 +85597,7 @@ "name": "RankVectorElementType", "namespace": "_types.mapping" }, - "specLocation": "_types/mapping/core.ts#L378-L382" + "specLocation": "_types/mapping/core.ts#L386-L390" }, { "kind": "interface", @@ -85589,7 +85644,7 @@ } } ], - "specLocation": "_types/mapping/core.ts#L216-L223" + "specLocation": "_types/mapping/core.ts#L217-L224" }, { "kind": "interface", @@ -85877,7 +85932,7 @@ } } ], - "specLocation": "_types/mapping/core.ts#L196-L200" + "specLocation": "_types/mapping/core.ts#L197-L201" }, { "kind": "interface", @@ -86012,7 +86067,7 @@ } } ], - "specLocation": "_types/mapping/core.ts#L255-L266" + "specLocation": "_types/mapping/core.ts#L263-L274" }, { "kind": "interface", @@ -86089,7 +86144,7 @@ } } ], - "specLocation": "_types/mapping/core.ts#L230-L253" + "specLocation": "_types/mapping/core.ts#L238-L261" }, { "kind": "interface", @@ -86195,7 +86250,7 @@ } } ], - "specLocation": "_types/mapping/core.ts#L181-L184" + "specLocation": "_types/mapping/core.ts#L182-L185" }, { "kind": "interface", @@ -86320,6 +86375,54 @@ }, "specLocation": "_types/mapping/meta-fields.ts#L67-L75" }, + { + "kind": "interface", + "name": { + "name": "SparseVectorIndexOptions", + "namespace": "_types.mapping" + }, + "properties": [ + { + "availability": { + "serverless": {}, + "stack": { + "since": "8.19.0" + } + }, + "containerProperty": true, + "description": "Whether to perform pruning, omitting the non-significant tokens from the query to improve query performance.\nIf prune is true but the pruning_config is not specified, pruning will occur but default values will be used.\nDefault: false", + "name": "prune", + "required": false, + "type": { + "kind": "instance_of", + "type": { + "name": "boolean", + "namespace": "_builtins" + } + } + }, + { + "availability": { + "serverless": {}, + "stack": { + "since": "8.19.0" + } + }, + "containerProperty": true, + "description": "Optional pruning configuration.\nIf enabled, this will omit non-significant tokens from the query in order to improve query performance.\nThis is only used if prune is set to true.\nIf prune is set to true but pruning_config is not specified, default values will be used.", + "name": "pruning_config", + "required": false, + "type": { + "kind": "instance_of", + "type": { + "name": "TokenPruningConfig", + "namespace": "_types" + } + } + } + ], + "specLocation": "_types/mapping/SparseVectorIndexOptions.ts#L22-L42" + }, { "kind": "interface", "inherits": { @@ -86351,9 +86454,27 @@ "kind": "literal_value", "value": "sparse_vector" } + }, + { + "availability": { + "serverless": {}, + "stack": { + "since": "8.19.0" + } + }, + "description": "Additional index options for the sparse vector field that controls the\ntoken pruning behavior of the sparse vector field.", + "name": "index_options", + "required": false, + "type": { + "kind": "instance_of", + "type": { + "name": "SparseVectorIndexOptions", + "namespace": "_types.mapping" + } + } } ], - "specLocation": "_types/mapping/core.ts#L225-L228" + "specLocation": "_types/mapping/core.ts#L226-L236" }, { "kind": "enum", @@ -86531,7 +86652,7 @@ } } ], - "specLocation": "_types/mapping/core.ts#L308-L311" + "specLocation": "_types/mapping/core.ts#L316-L319" }, { "kind": "interface", @@ -86744,7 +86865,7 @@ } } ], - "specLocation": "_types/mapping/core.ts#L313-L330" + "specLocation": "_types/mapping/core.ts#L321-L338" }, { "kind": "enum", @@ -87127,7 +87248,7 @@ } } ], - "specLocation": "_types/mapping/core.ts#L191-L194" + "specLocation": "_types/mapping/core.ts#L192-L195" }, { "kind": "interface", @@ -87151,7 +87272,7 @@ } } ], - "specLocation": "_types/mapping/core.ts#L332-L334" + "specLocation": "_types/mapping/core.ts#L340-L342" }, { "kind": "interface", @@ -87192,7 +87313,7 @@ } } ], - "specLocation": "_types/mapping/core.ts#L336-L343" + "specLocation": "_types/mapping/core.ts#L344-L351" }, { "kind": "interface", @@ -95366,7 +95487,7 @@ "kind": "instance_of", "type": { "name": "TokenPruningConfig", - "namespace": "_types.query_dsl" + "namespace": "_types" } } } @@ -95717,7 +95838,7 @@ "kind": "instance_of", "type": { "name": "TokenPruningConfig", - "namespace": "_types.query_dsl" + "namespace": "_types" } } } @@ -95758,55 +95879,6 @@ }, "specLocation": "_types/query_dsl/fulltext.ts#L610-L636" }, - { - "kind": "interface", - "name": { - "name": "TokenPruningConfig", - "namespace": "_types.query_dsl" - }, - "properties": [ - { - "description": "Tokens whose frequency is more than this threshold times the average frequency of all tokens in the specified field are considered outliers and pruned.", - "name": "tokens_freq_ratio_threshold", - "required": false, - "serverDefault": 5, - "type": { - "kind": "instance_of", - "type": { - "name": "integer", - "namespace": "_types" - } - } - }, - { - "description": "Tokens whose weight is less than this threshold are considered nonsignificant and pruned.", - "name": "tokens_weight_threshold", - "required": false, - "serverDefault": 0.4, - "type": { - "kind": "instance_of", - "type": { - "name": "float", - "namespace": "_types" - } - } - }, - { - "description": "Whether to only score pruned tokens, vs only scoring kept tokens.", - "name": "only_score_pruned_tokens", - "required": false, - "serverDefault": false, - "type": { - "kind": "instance_of", - "type": { - "name": "boolean", - "namespace": "_builtins" - } - } - } - ], - "specLocation": "_types/query_dsl/TokenPruningConfig.ts#L22-L35" - }, { "kind": "interface", "inherits": { @@ -96000,7 +96072,7 @@ "kind": "instance_of", "type": { "name": "TokenPruningConfig", - "namespace": "_types.query_dsl" + "namespace": "_types" } } } @@ -100698,6 +100770,584 @@ ] } }, + { + "kind": "enum", + "isOpen": true, + "members": [ + { + "aliases": [ + "cs", + "completionSize" + ], + "description": "Size of completion. For example: `0b`.", + "name": "completion.size" + }, + { + "description": "Disk space used by the shard’s dataset, which may or may not be the size on\ndisk, but includes space used by the shard on object storage. Reported as a size value for example: `5kb`.", + "name": "dataset.size" + }, + { + "aliases": [ + "dvc", + "denseVectorCount" + ], + "description": "Number of indexed dense vectors.", + "name": "dense_vector.value_count" + }, + { + "aliases": [ + "d", + "dc" + ], + "description": "Number of documents in shard, for example: `25`.", + "name": "docs" + }, + { + "aliases": [ + "fe", + "fielddataEvictions" + ], + "description": "Fielddata cache evictions, for example: `0`.", + "name": "fielddata.evictions" + }, + { + "aliases": [ + "fm", + "fielddataMemory" + ], + "description": "Used fielddata cache memory, for example: `0b`.", + "name": "fielddata.memory_size" + }, + { + "aliases": [ + "ft", + "flushTotal" + ], + "description": "Number of flushes, for example: `1`.", + "name": "flush.total" + }, + { + "aliases": [ + "ftt", + "flushTotalTime" + ], + "description": "Time spent in flush, for example: `1`.", + "name": "flush.total_time" + }, + { + "aliases": [ + "gc", + "getCurrent" + ], + "description": "Number of current get operations, for example: `0`.", + "name": "get.current" + }, + { + "aliases": [ + "geti", + "getExistsTime" + ], + "description": "Time spent in successful gets, for example: `14ms`.", + "name": "get.exists_time" + }, + { + "aliases": [ + "geto", + "getExistsTotal" + ], + "description": "Number of successful get operations, for example: `2`.", + "name": "get.exists_total" + }, + { + "aliases": [ + "gmti", + "getMissingTime" + ], + "description": "Time spent in failed gets, for example: `0s`.", + "name": "get.missing_time" + }, + { + "aliases": [ + "gmto", + "getMissingTotal" + ], + "description": "Number of failed get operations, for example: `1`.", + "name": "get.missing_total" + }, + { + "aliases": [ + "gti", + "getTime" + ], + "description": "Time spent in get, for example: `14ms`.", + "name": "get.time" + }, + { + "aliases": [ + "gto", + "getTotal" + ], + "description": "Number of get operations, for example: `2`.", + "name": "get.total" + }, + { + "description": "ID of the node, for example: `k0zy`.", + "name": "id" + }, + { + "aliases": [ + "i", + "idx" + ], + "description": "Name of the index.", + "name": "index" + }, + { + "aliases": [ + "idc", + "indexingDeleteCurrent" + ], + "description": "Number of current deletion operations, for example: `0`.", + "name": "indexing.delete_current" + }, + { + "aliases": [ + "idti", + "indexingDeleteTime" + ], + "description": "Time spent in deletions, for example: `2ms`.", + "name": "indexing.delete_time" + }, + { + "aliases": [ + "idto", + "indexingDeleteTotal" + ], + "description": "Number of deletion operations, for example: `2`.", + "name": "indexing.delete_total" + }, + { + "aliases": [ + "iic", + "indexingIndexCurrent" + ], + "description": "Number of current indexing operations, for example: `0`.", + "name": "indexing.index_current" + }, + { + "aliases": [ + "iifvc", + "indexingIndexFailedDueToVersionConflict" + ], + "description": "Number of failed indexing operations due to version conflict, for example: `0`.", + "name": "indexing.index_failed_due_to_version_conflict" + }, + { + "aliases": [ + "iif", + "indexingIndexFailed" + ], + "description": "Number of failed indexing operations, for example: `0`.", + "name": "indexing.index_failed" + }, + { + "aliases": [ + "iiti", + "indexingIndexTime" + ], + "description": "Time spent in indexing, such as for example: `134ms`.", + "name": "indexing.index_time" + }, + { + "aliases": [ + "iito", + "indexingIndexTotal" + ], + "description": "Number of indexing operations, for example: `1`.", + "name": "indexing.index_total" + }, + { + "description": "IP address of the node, for example: `127.0.1.1`.", + "name": "ip" + }, + { + "aliases": [ + "mc", + "mergesCurrent" + ], + "description": "Number of current merge operations, for example: `0`.", + "name": "merges.current" + }, + { + "aliases": [ + "mcd", + "mergesCurrentDocs" + ], + "description": "Number of current merging documents, for example: `0`.", + "name": "merges.current_docs" + }, + { + "aliases": [ + "mcs", + "mergesCurrentSize" + ], + "description": "Size of current merges, for example: `0b`.", + "name": "merges.current_size" + }, + { + "aliases": [ + "mt", + "mergesTotal" + ], + "description": "Number of completed merge operations, for example: `0`.", + "name": "merges.total" + }, + { + "aliases": [ + "mtd", + "mergesTotalDocs" + ], + "description": "Number of merged documents, for example: `0`.", + "name": "merges.total_docs" + }, + { + "aliases": [ + "mts", + "mergesTotalSize" + ], + "description": "Size of current merges, for example: `0b`.", + "name": "merges.total_size" + }, + { + "aliases": [ + "mtt", + "mergesTotalTime" + ], + "description": "Time spent merging documents, for example: `0s`.", + "name": "merges.total_time" + }, + { + "aliases": [ + "n" + ], + "description": "Node name, for example: `I8hydUG`.", + "name": "node" + }, + { + "aliases": [ + "p", + "pr", + "primaryOrReplica" + ], + "description": "Shard type. Returned values are `primary` or `replica`.", + "name": "prirep" + }, + { + "aliases": [ + "qce", + "queryCacheEvictions" + ], + "description": "Query cache evictions, for example: `0`.", + "name": "query_cache.evictions" + }, + { + "aliases": [ + "qcm", + "queryCacheMemory" + ], + "description": "Used query cache memory, for example: `0b`.", + "name": "query_cache.memory_size" + }, + { + "aliases": [ + "rs" + ], + "description": "Type of recovery source.", + "name": "recoverysource.type" + }, + { + "aliases": [ + "rti", + "refreshTime" + ], + "description": "Time spent in refreshes, for example: `91ms`.", + "name": "refresh.time" + }, + { + "aliases": [ + "rto", + "refreshTotal" + ], + "description": "Number of refreshes, for example: `16`.", + "name": "refresh.total" + }, + { + "aliases": [ + "sfc", + "searchFetchCurrent" + ], + "description": "Current fetch phase operations, for example: `0`.", + "name": "search.fetch_current" + }, + { + "aliases": [ + "sfti", + "searchFetchTime" + ], + "description": "Time spent in fetch phase, for example: `37ms`.", + "name": "search.fetch_time" + }, + { + "aliases": [ + "sfto", + "searchFetchTotal" + ], + "description": "Number of fetch operations, for example: `7`.", + "name": "search.fetch_total" + }, + { + "aliases": [ + "so", + "searchOpenContexts" + ], + "description": "Open search contexts, for example: `0`.", + "name": "search.open_contexts" + }, + { + "aliases": [ + "sqc", + "searchQueryCurrent" + ], + "description": "Current query phase operations, for example: `0`.", + "name": "search.query_current" + }, + { + "aliases": [ + "sqti", + "searchQueryTime" + ], + "description": "Time spent in query phase, for example: `43ms`.", + "name": "search.query_time" + }, + { + "aliases": [ + "sqto", + "searchQueryTotal" + ], + "description": "Number of query operations, for example: `9`.", + "name": "search.query_total" + }, + { + "aliases": [ + "scc", + "searchScrollCurrent" + ], + "description": "Open scroll contexts, for example: `2`.", + "name": "search.scroll_current" + }, + { + "aliases": [ + "scti", + "searchScrollTime" + ], + "description": "Time scroll contexts held open, for example: `2m`.", + "name": "search.scroll_time" + }, + { + "aliases": [ + "scto", + "searchScrollTotal" + ], + "description": "Completed scroll contexts, for example: `1`.", + "name": "search.scroll_total" + }, + { + "aliases": [ + "sc", + "segmentsCount" + ], + "description": "Number of segments, for example: `4`.", + "name": "segments.count" + }, + { + "aliases": [ + "sfbm", + "fixedBitsetMemory" + ], + "description": "Memory used by fixed bit sets for nested object field types and type filters for types referred in join fields, for example: `1.0kb`.", + "name": "segments.fixed_bitset_memory" + }, + { + "aliases": [ + "siwm", + "segmentsIndexWriterMemory" + ], + "description": "Memory used by index writer, for example: `18mb`.", + "name": "segments.index_writer_memory" + }, + { + "aliases": [ + "sm", + "segmentsMemory" + ], + "description": "Memory used by segments, for example: `1.4kb`.", + "name": "segments.memory" + }, + { + "aliases": [ + "svmm", + "segmentsVersionMapMemory" + ], + "description": "Memory used by version map, for example: `1.0kb`.", + "name": "segments.version_map_memory" + }, + { + "aliases": [ + "sqg", + "globalCheckpoint" + ], + "description": "Global checkpoint.", + "name": "seq_no.global_checkpoint" + }, + { + "aliases": [ + "sql", + "localCheckpoint" + ], + "description": "Local checkpoint.", + "name": "seq_no.local_checkpoint" + }, + { + "aliases": [ + "sqm", + "maxSeqNo" + ], + "description": "Maximum sequence number.", + "name": "seq_no.max" + }, + { + "aliases": [ + "s", + "sh" + ], + "description": "Name of the shard.", + "name": "shard" + }, + { + "aliases": [ + "svc", + "sparseVectorCount" + ], + "description": "Number of indexed [sparse vectors](https://www.elastic.co/docs/reference/elasticsearch/mapping-reference/sparse-vector).", + "name": "dsparse_vector.value_count" + }, + { + "aliases": [ + "st" + ], + "description": "State of the shard. Returned values are:\n* `INITIALIZING`: The shard is recovering from a peer shard or gateway.\n* `RELOCATING`: The shard is relocating.\n* `STARTED`: The shard has started.\n* `UNASSIGNED`: The shard is not assigned to any node.", + "name": "state" + }, + { + "aliases": [ + "sto" + ], + "description": "Disk space used by the shard, for example: `5kb`.", + "name": "store" + }, + { + "aliases": [ + "suc", + "suggestCurrent" + ], + "description": "Number of current suggest operations, for example: `0`.", + "name": "suggest.current" + }, + { + "aliases": [ + "suti", + "suggestTime" + ], + "description": "Time spent in suggest, for example: `0`.", + "name": "suggest.time" + }, + { + "aliases": [ + "suto", + "suggestTotal" + ], + "description": "Number of suggest operations, for example: `0`.", + "name": "suggest.total" + }, + { + "description": "Sync ID of the shard.", + "name": "sync_id" + }, + { + "aliases": [ + "ua" + ], + "description": "Time at which the shard became unassigned in [Coordinated Universal Time (UTC)](https://en.wikipedia.org/wiki/List_of_UTC_offsets).", + "name": "unassigned.at" + }, + { + "aliases": [ + "ud" + ], + "description": "Details about why the shard became unassigned. This does not explain why the shard is currently unassigned. To understand why a shard\nis not assigned, use the [Cluster allocation explain](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-cluster-allocation-explain) API.", + "name": "unassigned.details" + }, + { + "aliases": [ + "uf" + ], + "description": "Time at which the shard was requested to be unassigned in [Coordinated Universal Time (UTC)](https://en.wikipedia.org/wiki/List_of_UTC_offsets).", + "name": "unassigned.for" + }, + { + "aliases": [ + "ur" + ], + "description": "Indicates the reason for the last change to the state of this unassigned shard. This does not explain why the shard is currently unassigned.\nTo understand why a shard is not assigned, use the [Cluster allocation explain](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-cluster-allocation-explain) API. Returned values include:\n\n* `ALLOCATION_FAILED`: Unassigned as a result of a failed allocation of the shard.\n* `CLUSTER_RECOVERED`: Unassigned as a result of a full cluster recovery.\n* `DANGLING_INDEX_IMPORTED`: Unassigned as a result of importing a dangling index.\n* `EXISTING_INDEX_RESTORED`: Unassigned as a result of restoring into a closed index.\n* `FORCED_EMPTY_PRIMARY`: The shard’s allocation was last modified by forcing an empty primary using the Cluster reroute API.\n* `INDEX_CLOSED`: Unassigned because the index was closed.\n* `INDEX_CREATED`: Unassigned as a result of an API creation of an index.\n* `INDEX_REOPENED`: Unassigned as a result of opening a closed index.\n* `MANUAL_ALLOCATION`: The shard’s allocation was last modified by the Cluster reroute API.\n* `NEW_INDEX_RESTORED`: Unassigned as a result of restoring into a new index.\n* `NODE_LEFT`: Unassigned as a result of the node hosting it leaving the cluster.\n* `NODE_RESTARTING`: Similar to `NODE_LEFT`, except that the node was registered as restarting using the Node shutdown API.\n* `PRIMARY_FAILED`: The shard was initializing as a replica, but the primary shard failed before the initialization completed.\n* `REALLOCATED_REPLICA`: A better replica location is identified and causes the existing replica allocation to be cancelled.\n* `REINITIALIZED`: When a shard moves from started back to initializing.\n* `REPLICA_ADDED`: Unassigned as a result of explicit addition of a replica.\n* `REROUTE_CANCELLED`: Unassigned as a result of explicit cancel reroute command.", + "name": "unassigned.reason" + } + ], + "name": { + "name": "CatShardColumn", + "namespace": "cat._types" + }, + "specLocation": "cat/_types/CatBase.ts#L1576-L1949" + }, + { + "kind": "type_alias", + "name": { + "name": "CatShardColumns", + "namespace": "cat._types" + }, + "specLocation": "cat/_types/CatBase.ts#L1950-L1950", + "type": { + "kind": "union_of", + "items": [ + { + "kind": "instance_of", + "type": { + "name": "CatShardColumn", + "namespace": "cat._types" + } + }, + { + "kind": "array_of", + "value": { + "kind": "instance_of", + "type": { + "name": "CatShardColumn", + "namespace": "cat._types" + } + } + } + ] + } + }, { "kind": "enum", "isOpen": true, @@ -100835,6 +101485,181 @@ ] } }, + { + "kind": "enum", + "isOpen": true, + "members": [ + { + "aliases": [ + "a" + ], + "description": "Number of active threads in the current thread pool.", + "name": "active" + }, + { + "aliases": [ + "c" + ], + "description": "Number of tasks completed by the thread pool executor.", + "name": "completed" + }, + { + "aliases": [ + "cr" + ], + "description": "Configured core number of active threads allowed in the current thread pool.", + "name": "core" + }, + { + "aliases": [ + "eid" + ], + "description": "Ephemeral node ID.", + "name": "ephemeral_id" + }, + { + "aliases": [ + "h" + ], + "description": "Hostname for the current node.", + "name": "host" + }, + { + "aliases": [ + "i" + ], + "description": "IP address for the current node.", + "name": "ip" + }, + { + "aliases": [ + "k" + ], + "description": "Configured keep alive time for threads.", + "name": "keep_alive" + }, + { + "aliases": [ + "l" + ], + "description": "Highest number of active threads in the current thread pool.", + "name": "largest" + }, + { + "aliases": [ + "mx" + ], + "description": "Configured maximum number of active threads allowed in the current thread pool.", + "name": "max" + }, + { + "description": "Name of the thread pool, such as `analyze` or `generic`.", + "name": "name" + }, + { + "aliases": [ + "id" + ], + "description": "ID of the node, such as `k0zy`.", + "name": "node_id" + }, + { + "description": "Node name, such as `I8hydUG`.", + "name": "node_name" + }, + { + "aliases": [ + "p" + ], + "description": "Process ID of the running node.", + "name": "pid" + }, + { + "aliases": [ + "psz" + ], + "description": "Number of threads in the current thread pool.", + "name": "pool_size" + }, + { + "aliases": [ + "po" + ], + "description": "Bound transport port for the current node.", + "name": "port" + }, + { + "aliases": [ + "q" + ], + "description": "Number of tasks in the queue for the current thread pool.", + "name": "queue" + }, + { + "aliases": [ + "qs" + ], + "description": "Maximum number of tasks permitted in the queue for the current thread pool.", + "name": "queue_size" + }, + { + "aliases": [ + "r" + ], + "description": "Number of tasks rejected by the thread pool executor.", + "name": "rejected" + }, + { + "aliases": [ + "sz" + ], + "description": "Configured fixed number of active threads allowed in the current thread pool.", + "name": "size" + }, + { + "aliases": [ + "t" + ], + "description": "Type of thread pool. Returned values are `fixed`, `fixed_auto_queue_size`, `direct`, or `scaling`.", + "name": "type" + } + ], + "name": { + "name": "CatThreadPoolColumn", + "namespace": "cat._types" + }, + "specLocation": "cat/_types/CatBase.ts#L1952-L2052" + }, + { + "kind": "type_alias", + "name": { + "name": "CatThreadPoolColumns", + "namespace": "cat._types" + }, + "specLocation": "cat/_types/CatBase.ts#L2053-L2053", + "type": { + "kind": "union_of", + "items": [ + { + "kind": "instance_of", + "type": { + "name": "CatThreadPoolColumn", + "namespace": "cat._types" + } + }, + { + "kind": "array_of", + "value": { + "kind": "instance_of", + "type": { + "name": "CatThreadPoolColumn", + "namespace": "cat._types" + } + } + } + ] + } + }, { "kind": "enum", "members": [ @@ -111670,13 +112495,13 @@ "type": { "kind": "instance_of", "type": { - "name": "Names", - "namespace": "_types" + "name": "CatShardColumns", + "namespace": "cat._types" } } }, { - "description": "List of columns that determine how the table should be sorted.\nSorting defaults to ascending and can be changed by setting `:asc`\nor `:desc` as a suffix to the column name.", + "description": "A comma-separated list of column names or aliases that determines the sort order.\nSorting defaults to ascending and can be changed by setting `:asc`\nor `:desc` as a suffix to the column name.", "name": "s", "required": false, "type": { @@ -111688,7 +112513,7 @@ } }, { - "description": "Period to wait for a connection to the master node.", + "description": "The period to wait for a connection to the master node.", "name": "master_timeout", "required": false, "serverDefault": "30s", @@ -111701,7 +112526,7 @@ } }, { - "description": "Unit used to display time values.", + "description": "The unit used to display time values.", "name": "time", "required": false, "type": { @@ -114216,13 +115041,13 @@ "type": { "kind": "instance_of", "type": { - "name": "Names", - "namespace": "_types" + "name": "CatThreadPoolColumns", + "namespace": "cat._types" } } }, { - "description": "List of columns that determine how the table should be sorted.\nSorting defaults to ascending and can be changed by setting `:asc`\nor `:desc` as a suffix to the column name.", + "description": "A comma-separated list of column names or aliases that determines the sort order.\nSorting defaults to ascending and can be changed by setting `:asc`\nor `:desc` as a suffix to the column name.", "name": "s", "required": false, "type": { @@ -114259,7 +115084,7 @@ } }, { - "description": "Period to wait for a connection to the master node.", + "description": "The period to wait for a connection to the master node.", "name": "master_timeout", "required": false, "serverDefault": "30s", @@ -223053,7 +223878,7 @@ "description": "", "version": "8.11.0" }, - "description": "Search rolled-up data.\nThe rollup search endpoint is needed because, internally, rolled-up documents utilize a different document structure than the original data.\nIt rewrites standard Query DSL into a format that matches the rollup documents then takes the response and rewrites it back to what a client would expect given the original query.\n\nThe request body supports a subset of features from the regular search API.\nThe following functionality is not available:\n\n`size`: Because rollups work on pre-aggregated data, no search hits can be returned and so size must be set to zero or omitted entirely.\n`highlighter`, `suggestors`, `post_filter`, `profile`, `explain`: These are similarly disallowed.\n\n**Searching both historical rollup and non-rollup data**\n\nThe rollup search API has the capability to search across both \"live\" non-rollup data and the aggregated rollup data.\nThis is done by simply adding the live indices to the URI. For example:\n\n```\nGET sensor-1,sensor_rollup/_rollup_search\n{\n \"size\": 0,\n \"aggregations\": {\n \"max_temperature\": {\n \"max\": {\n \"field\": \"temperature\"\n }\n }\n }\n}\n```\n\nThe rollup search endpoint does two things when the search runs:\n\n* The original request is sent to the non-rollup index unaltered.\n* A rewritten version of the original request is sent to the rollup index.\n\nWhen the two responses are received, the endpoint rewrites the rollup response and merges the two together.\nDuring the merging process, if there is any overlap in buckets between the two responses, the buckets from the non-rollup index are used.", + "description": "Search rolled-up data.\nThe rollup search endpoint is needed because, internally, rolled-up documents utilize a different document structure than the original data.\nIt rewrites standard Query DSL into a format that matches the rollup documents then takes the response and rewrites it back to what a client would expect given the original query.\n\nThe request body supports a subset of features from the regular search API.\nThe following functionality is not available:\n\n`size`: Because rollups work on pre-aggregated data, no search hits can be returned and so size must be set to zero or omitted entirely.\n`highlighter`, `suggestors`, `post_filter`, `profile`, `explain`: These are similarly disallowed.\n\nFor more detailed examples of using the rollup search API, including querying rolled-up data only or combining rolled-up and live data, refer to the External documentation.", "examples": { "RollupSearchRequestExample1": { "alternatives": [ @@ -223137,7 +223962,7 @@ } } ], - "specLocation": "rollup/rollup_search/RollupSearchRequest.ts#L27-L109" + "specLocation": "rollup/rollup_search/RollupSearchRequest.ts#L27-L86" }, { "kind": "response", diff --git a/output/typescript/types.ts b/output/typescript/types.ts index 2384b7e5da..a84fde9660 100644 --- a/output/typescript/types.ts +++ b/output/typescript/types.ts @@ -2987,6 +2987,12 @@ export type TimeUnit = 'nanos' | 'micros' | 'ms' | 's' | 'm' | 'h' | 'd' export type TimeZone = string +export interface TokenPruningConfig { + tokens_freq_ratio_threshold?: integer + tokens_weight_threshold?: float + only_score_pruned_tokens?: boolean +} + export interface TopLeftBottomRightGeoBounds { top_left: GeoLocation bottom_right: GeoLocation @@ -6017,9 +6023,15 @@ export interface MappingSourceField { export type MappingSourceFieldMode = 'disabled' | 'stored' | 'synthetic' +export interface MappingSparseVectorIndexOptions { + prune?: boolean + pruning_config?: TokenPruningConfig +} + export interface MappingSparseVectorProperty extends MappingPropertyBase { store?: boolean type: 'sparse_vector' + index_options?: MappingSparseVectorIndexOptions } export type MappingSubobjects = boolean | 'true' | 'false' | 'auto' @@ -6850,7 +6862,7 @@ export interface QueryDslSparseVectorQuery extends QueryDslQueryBase { inference_id?: Id query?: string prune?: boolean - pruning_config?: QueryDslTokenPruningConfig + pruning_config?: TokenPruningConfig } export interface QueryDslTermQuery extends QueryDslQueryBase { @@ -6885,17 +6897,11 @@ export interface QueryDslTermsSetQuery extends QueryDslQueryBase { export interface QueryDslTextExpansionQuery extends QueryDslQueryBase { model_id: string model_text: string - pruning_config?: QueryDslTokenPruningConfig + pruning_config?: TokenPruningConfig } export type QueryDslTextQueryType = 'best_fields' | 'most_fields' | 'cross_fields' | 'phrase' | 'phrase_prefix' | 'bool_prefix' -export interface QueryDslTokenPruningConfig { - tokens_freq_ratio_threshold?: integer - tokens_weight_threshold?: float - only_score_pruned_tokens?: boolean -} - export interface QueryDslTypeQuery extends QueryDslQueryBase { value: string } @@ -6915,7 +6921,7 @@ export interface QueryDslUntypedRangeQuery extends QueryDslRangeQueryBase { export interface QueryDslWeightedTokensQuery extends QueryDslQueryBase { tokens: Record | Record[] - pruning_config?: QueryDslTokenPruningConfig + pruning_config?: TokenPruningConfig } export interface QueryDslWildcardQuery extends QueryDslQueryBase { @@ -7167,10 +7173,18 @@ export type CatCatSegmentsColumn = 'index' | 'i' | 'idx' | 'shard' | 's' | 'sh' export type CatCatSegmentsColumns = CatCatSegmentsColumn | CatCatSegmentsColumn[] +export type CatCatShardColumn = 'completion.size' | 'cs' | 'completionSize' | 'dataset.size' | 'dense_vector.value_count' | 'dvc' | 'denseVectorCount' | 'docs' | 'd' | 'dc' | 'fielddata.evictions' | 'fe' | 'fielddataEvictions' | 'fielddata.memory_size' | 'fm' | 'fielddataMemory' | 'flush.total' | 'ft' | 'flushTotal' | 'flush.total_time' | 'ftt' | 'flushTotalTime' | 'get.current' | 'gc' | 'getCurrent' | 'get.exists_time' | 'geti' | 'getExistsTime' | 'get.exists_total' | 'geto' | 'getExistsTotal' | 'get.missing_time' | 'gmti' | 'getMissingTime' | 'get.missing_total' | 'gmto' | 'getMissingTotal' | 'get.time' | 'gti' | 'getTime' | 'get.total' | 'gto' | 'getTotal' | 'id' | 'index' | 'i' | 'idx' | 'indexing.delete_current' | 'idc' | 'indexingDeleteCurrent' | 'indexing.delete_time' | 'idti' | 'indexingDeleteTime' | 'indexing.delete_total' | 'idto' | 'indexingDeleteTotal' | 'indexing.index_current' | 'iic' | 'indexingIndexCurrent' | 'indexing.index_failed_due_to_version_conflict' | 'iifvc' | 'indexingIndexFailedDueToVersionConflict' | 'indexing.index_failed' | 'iif' | 'indexingIndexFailed' | 'indexing.index_time' | 'iiti' | 'indexingIndexTime' | 'indexing.index_total' | 'iito' | 'indexingIndexTotal' | 'ip' | 'merges.current' | 'mc' | 'mergesCurrent' | 'merges.current_docs' | 'mcd' | 'mergesCurrentDocs' | 'merges.current_size' | 'mcs' | 'mergesCurrentSize' | 'merges.total' | 'mt' | 'mergesTotal' | 'merges.total_docs' | 'mtd' | 'mergesTotalDocs' | 'merges.total_size' | 'mts' | 'mergesTotalSize' | 'merges.total_time' | 'mtt' | 'mergesTotalTime' | 'node' | 'n' | 'prirep' | 'p' | 'pr' | 'primaryOrReplica' | 'query_cache.evictions' | 'qce' | 'queryCacheEvictions' | 'query_cache.memory_size' | 'qcm' | 'queryCacheMemory' | 'recoverysource.type' | 'rs' | 'refresh.time' | 'rti' | 'refreshTime' | 'refresh.total' | 'rto' | 'refreshTotal' | 'search.fetch_current' | 'sfc' | 'searchFetchCurrent' | 'search.fetch_time' | 'sfti' | 'searchFetchTime' | 'search.fetch_total' | 'sfto' | 'searchFetchTotal' | 'search.open_contexts' | 'so' | 'searchOpenContexts' | 'search.query_current' | 'sqc' | 'searchQueryCurrent' | 'search.query_time' | 'sqti' | 'searchQueryTime' | 'search.query_total' | 'sqto' | 'searchQueryTotal' | 'search.scroll_current' | 'scc' | 'searchScrollCurrent' | 'search.scroll_time' | 'scti' | 'searchScrollTime' | 'search.scroll_total' | 'scto' | 'searchScrollTotal' | 'segments.count' | 'sc' | 'segmentsCount' | 'segments.fixed_bitset_memory' | 'sfbm' | 'fixedBitsetMemory' | 'segments.index_writer_memory' | 'siwm' | 'segmentsIndexWriterMemory' | 'segments.memory' | 'sm' | 'segmentsMemory' | 'segments.version_map_memory' | 'svmm' | 'segmentsVersionMapMemory' | 'seq_no.global_checkpoint' | 'sqg' | 'globalCheckpoint' | 'seq_no.local_checkpoint' | 'sql' | 'localCheckpoint' | 'seq_no.max' | 'sqm' | 'maxSeqNo' | 'shard' | 's' | 'sh' | 'dsparse_vector.value_count' | 'svc' | 'sparseVectorCount' | 'state' | 'st' | 'store' | 'sto' | 'suggest.current' | 'suc' | 'suggestCurrent' | 'suggest.time' | 'suti' | 'suggestTime' | 'suggest.total' | 'suto' | 'suggestTotal' | 'sync_id' | 'unassigned.at' | 'ua' | 'unassigned.details' | 'ud' | 'unassigned.for' | 'uf' | 'unassigned.reason' | 'ur'| string + +export type CatCatShardColumns = CatCatShardColumn | CatCatShardColumn[] + export type CatCatSnapshotsColumn = 'id' | 'snapshot' | 'repository' | 're' | 'repo' | 'status' | 's' | 'start_epoch' | 'ste' | 'startEpoch' | 'start_time' | 'sti' | 'startTime' | 'end_epoch' | 'ete' | 'endEpoch' | 'end_time' | 'eti' | 'endTime' | 'duration' | 'dur' | 'indices' | 'i' | 'successful_shards' | 'ss' | 'failed_shards' | 'fs' | 'total_shards' | 'ts' | 'reason' | 'r'| string export type CatCatSnapshotsColumns = CatCatSnapshotsColumn | CatCatNodeColumn[] +export type CatCatThreadPoolColumn = 'active' | 'a' | 'completed' | 'c' | 'core' | 'cr' | 'ephemeral_id' | 'eid' | 'host' | 'h' | 'ip' | 'i' | 'keep_alive' | 'k' | 'largest' | 'l' | 'max' | 'mx' | 'name' | 'node_id' | 'id' | 'node_name' | 'pid' | 'p' | 'pool_size' | 'psz' | 'port' | 'po' | 'queue' | 'q' | 'queue_size' | 'qs' | 'rejected' | 'r' | 'size' | 'sz' | 'type' | 't'| string + +export type CatCatThreadPoolColumns = CatCatThreadPoolColumn | CatCatThreadPoolColumn[] + export type CatCatTrainedModelsColumn = 'create_time' | 'ct' | 'created_by' | 'c' | 'createdBy' | 'data_frame_analytics_id' | 'df' | 'dataFrameAnalytics' | 'dfid' | 'description' | 'd' | 'heap_size' | 'hs' | 'modelHeapSize' | 'id' | 'ingest.count' | 'ic' | 'ingestCount' | 'ingest.current' | 'icurr' | 'ingestCurrent' | 'ingest.failed' | 'if' | 'ingestFailed' | 'ingest.pipelines' | 'ip' | 'ingestPipelines' | 'ingest.time' | 'it' | 'ingestTime' | 'license' | 'l' | 'operations' | 'o' | 'modelOperations' | 'version' | 'v' export type CatCatTrainedModelsColumns = CatCatTrainedModelsColumn | CatCatTrainedModelsColumn[] @@ -8552,7 +8566,7 @@ export interface CatSegmentsSegmentsRecord { export interface CatShardsRequest extends CatCatRequestBase { index?: Indices bytes?: Bytes - h?: Names + h?: CatCatShardColumns s?: Names master_timeout?: Duration time?: TimeUnit @@ -8895,7 +8909,7 @@ export interface CatTemplatesTemplatesRecord { export interface CatThreadPoolRequest extends CatCatRequestBase { thread_pool_patterns?: Names - h?: Names + h?: CatCatThreadPoolColumns s?: Names time?: TimeUnit local?: boolean diff --git a/specification/_types/query_dsl/TokenPruningConfig.ts b/specification/_types/TokenPruningConfig.ts similarity index 100% rename from specification/_types/query_dsl/TokenPruningConfig.ts rename to specification/_types/TokenPruningConfig.ts diff --git a/specification/_types/mapping/SparseVectorIndexOptions.ts b/specification/_types/mapping/SparseVectorIndexOptions.ts new file mode 100644 index 0000000000..e7a650a3a2 --- /dev/null +++ b/specification/_types/mapping/SparseVectorIndexOptions.ts @@ -0,0 +1,42 @@ +/* + * Licensed to Elasticsearch B.V. under one or more contributor + * license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright + * ownership. Elasticsearch B.V. licenses this file to you under + * the Apache License, Version 2.0 (the "License"); you may + * not use this file except in compliance with the License. + * You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ + +import { TokenPruningConfig } from '@_types/TokenPruningConfig' + +export class SparseVectorIndexOptions { + /** + * Whether to perform pruning, omitting the non-significant tokens from the query to improve query performance. + * If prune is true but the pruning_config is not specified, pruning will occur but default values will be used. + * Default: false + * @availability stack since=8.19.0 + * @availability serverless + * @variant container_property + */ + prune?: boolean + /** + * Optional pruning configuration. + * If enabled, this will omit non-significant tokens from the query in order to improve query performance. + * This is only used if prune is set to true. + * If prune is set to true but pruning_config is not specified, default values will be used. + * @availability stack since=8.19.0 + * @availability serverless + * @variant container_property + */ + pruning_config?: TokenPruningConfig +} diff --git a/specification/_types/mapping/core.ts b/specification/_types/mapping/core.ts index 66c4c6c952..33377fce93 100644 --- a/specification/_types/mapping/core.ts +++ b/specification/_types/mapping/core.ts @@ -40,6 +40,7 @@ import { NumericFielddata } from '@indices/_types/NumericFielddata' import { Dictionary } from '@spec_utils/Dictionary' import { ChunkingSettings } from './ChunkingSettings' import { Property, PropertyBase } from './Property' +import { SparseVectorIndexOptions } from './SparseVectorIndexOptions' import { TermVectorOption } from './TermVectorOption' import { TimeSeriesMetricType } from './TimeSeriesMetricType' @@ -225,6 +226,13 @@ export class RankVectorProperty extends PropertyBase { export class SparseVectorProperty extends PropertyBase { store?: boolean type: 'sparse_vector' + /** + * Additional index options for the sparse vector field that controls the + * token pruning behavior of the sparse vector field. + * @availability stack since=8.19.0 + * @availability serverless + */ + index_options?: SparseVectorIndexOptions } export class SemanticTextProperty { diff --git a/specification/_types/query_dsl/SparseVectorQuery.ts b/specification/_types/query_dsl/SparseVectorQuery.ts index c2164bb3db..b1a6129754 100644 --- a/specification/_types/query_dsl/SparseVectorQuery.ts +++ b/specification/_types/query_dsl/SparseVectorQuery.ts @@ -20,8 +20,8 @@ import { Field, Id } from '@_types/common' import { float } from '@_types/Numeric' import { Dictionary } from '@spec_utils/Dictionary' +import { TokenPruningConfig } from '../TokenPruningConfig' import { QueryBase } from './abstractions' -import { TokenPruningConfig } from './TokenPruningConfig' /** * @variants container diff --git a/specification/_types/query_dsl/TextExpansionQuery.ts b/specification/_types/query_dsl/TextExpansionQuery.ts index 238c079349..7d55520c5e 100644 --- a/specification/_types/query_dsl/TextExpansionQuery.ts +++ b/specification/_types/query_dsl/TextExpansionQuery.ts @@ -17,8 +17,8 @@ * under the License. */ +import { TokenPruningConfig } from '../TokenPruningConfig' import { QueryBase } from './abstractions' -import { TokenPruningConfig } from './TokenPruningConfig' /** * @ext_doc_id query-dsl-text-expansion-query diff --git a/specification/_types/query_dsl/WeightedTokensQuery.ts b/specification/_types/query_dsl/WeightedTokensQuery.ts index 17f965510f..42fc4ab205 100644 --- a/specification/_types/query_dsl/WeightedTokensQuery.ts +++ b/specification/_types/query_dsl/WeightedTokensQuery.ts @@ -19,8 +19,8 @@ import { float } from '@_types/Numeric' import { Dictionary } from '@spec_utils/Dictionary' +import { TokenPruningConfig } from '../TokenPruningConfig' import { QueryBase } from './abstractions' -import { TokenPruningConfig } from './TokenPruningConfig' /** * @ext_doc_id query-dsl-weighted-tokens-query