diff --git a/docs/reference/analysis/tokenfilters/uppercase-tokenfilter.asciidoc b/docs/reference/analysis/tokenfilters/uppercase-tokenfilter.asciidoc index 3d0fae996d1..0e68a8b6834 100644 --- a/docs/reference/analysis/tokenfilters/uppercase-tokenfilter.asciidoc +++ b/docs/reference/analysis/tokenfilters/uppercase-tokenfilter.asciidoc @@ -1,7 +1,7 @@ [[analysis-uppercase-tokenfilter]] === Uppercase Token Filter -coming[1.2.0] +added[1.2.0] A token filter of type `uppercase` that normalizes token text to upper case. diff --git a/docs/reference/index-modules/fielddata.asciidoc b/docs/reference/index-modules/fielddata.asciidoc index 8d4a4d0654b..3a8ab02256d 100644 --- a/docs/reference/index-modules/fielddata.asciidoc +++ b/docs/reference/index-modules/fielddata.asciidoc @@ -127,7 +127,7 @@ field data format. [float] ==== Global ordinals -coming[1.2.0] +added[1.2.0] Global ordinals is a data-structure on top of field data, that maintains an incremental numbering for all the terms in field data in a lexicographic order. diff --git a/docs/reference/mapping/types/core-types.asciidoc b/docs/reference/mapping/types/core-types.asciidoc index 14cf1ced982..96a7d6ee82f 100644 --- a/docs/reference/mapping/types/core-types.asciidoc +++ b/docs/reference/mapping/types/core-types.asciidoc @@ -181,7 +181,7 @@ you don't need scoring on a specific field, it is highly recommended to disable norms on it. In particular, this is the case for fields that are used solely for filtering or aggregations. -coming[1.2.0] +added[1.2.0] In case you would like to disable norms after the fact, it is possible to do so by using the <>. Please however note that norms won't be removed instantly, but as your index will receive new insertions diff --git a/docs/reference/modules/plugins.asciidoc b/docs/reference/modules/plugins.asciidoc index bd417f92574..1e8e74e1081 100644 --- a/docs/reference/modules/plugins.asciidoc +++ b/docs/reference/modules/plugins.asciidoc @@ -145,7 +145,7 @@ bin/plugin --install mobz/elasticsearch-head --timeout 0 [float] ==== Lucene version dependent plugins -coming[1.2.0] +added[1.2.0] For some plugins, such as analysis plugins, a specific major Lucene version is required to run. In that case, the plugin provides in its `es-plugin.properties` diff --git a/docs/reference/modules/tribe.asciidoc b/docs/reference/modules/tribe.asciidoc index 9f075685eea..0cc25434779 100644 --- a/docs/reference/modules/tribe.asciidoc +++ b/docs/reference/modules/tribe.asciidoc @@ -56,7 +56,7 @@ tribe: metadata: true -------------------------------- -coming[1.2.0] +added[1.2.0] The tribe node can also configure blocks on indices explicitly: @@ -67,7 +67,7 @@ tribe: indices.write: hk*,ldn* -------------------------------- -coming[1.2.0] +added[1.2.0] When there is a conflict and multiple clusters hold the same index, by default the tribe node will pick one of them. This can be configured using the `tribe.on_conflict` diff --git a/docs/reference/search/aggregations/bucket/significantterms-aggregation.asciidoc b/docs/reference/search/aggregations/bucket/significantterms-aggregation.asciidoc index a2c66ebd150..d611b0267a8 100644 --- a/docs/reference/search/aggregations/bucket/significantterms-aggregation.asciidoc +++ b/docs/reference/search/aggregations/bucket/significantterms-aggregation.asciidoc @@ -292,7 +292,7 @@ If the number of unique terms is greater than `size`, the returned list can be s (it could be that the term counts are slightly off and it could even be that a term that should have been in the top size buckets was not returned). -coming[1.2.0] If set to `0`, the `size` will be set to `Integer.MAX_VALUE`. +added[1.2.0] If set to `0`, the `size` will be set to `Integer.MAX_VALUE`. To ensure better accuracy a multiple of the final `size` is used as the number of terms to request from each shard using a heuristic based on the number of shards. To take manual control of this setting the `shard_size` parameter @@ -305,7 +305,7 @@ a consolidated review by the reducing node before the final selection. Obviously will cause extra network traffic and RAM usage so this is quality/cost trade off that needs to be balanced. If `shard_size` is set to -1 (the default) then `shard_size` will be automatically estimated based on the number of shards and the `size` parameter. -coming[1.2.0] If set to `0`, the `shard_size` will be set to `Integer.MAX_VALUE`. +added[1.2.0] If set to `0`, the `shard_size` will be set to `Integer.MAX_VALUE`. NOTE: `shard_size` cannot be smaller than `size` (as it doesn't make much sense). When it is, elasticsearch will @@ -336,7 +336,7 @@ The above aggregation would only return tags which have been found in 10 hits or Terms that score highly will be collected on a shard level and merged with the terms collected from other shards in a second step. However, the shard does not have the information about the global term frequencies available. The decision if a term is added to a candidate list depends only on the score computed on the shard using local shard frequencies, not the global frequencies of the word. The `min_doc_count` criterion is only applied after merging local terms statistics of all shards. In a way the decision to add the term as a candidate is made without being very _certain_ about if the term will actually reach the required `min_doc_count`. This might cause many (globally) high frequent terms to be missing in the final result if low frequent but high scoring terms populated the candidate lists. To avoid this, the `shard_size` parameter can be increased to allow more candidate terms on the shards. However, this increases memory consumption and network traffic. -coming[1.2.0] `shard_min_doc_count` parameter +added[1.2.0] `shard_min_doc_count` parameter The parameter `shard_min_doc_count` regulates the _certainty_ a shard has if the term should actually be added to the candidate list or not with respect to the `min_doc_count`. Terms will only be considered if their local shard frequency within the set is higher than the `shard_min_doc_count`. If your dictionary contains many low frequent words and you are not interested in these (for example misspellings), then you can set the `shard_min_doc_count` parameter to filter out candidate terms on a shard level that will with a resonable certainty not reach the required `min_doc_count` even after merging the local frequencies. `shard_min_doc_count` is set to `1` per default and has no effect unless you explicitly set it. diff --git a/docs/reference/search/aggregations/bucket/terms-aggregation.asciidoc b/docs/reference/search/aggregations/bucket/terms-aggregation.asciidoc index ab725ac7491..b33301b3d16 100644 --- a/docs/reference/search/aggregations/bucket/terms-aggregation.asciidoc +++ b/docs/reference/search/aggregations/bucket/terms-aggregation.asciidoc @@ -209,7 +209,7 @@ The above aggregation would only return tags which have been found in 10 hits or Terms are collected and ordered on a shard level and merged with the terms collected from other shards in a second step. However, the shard does not have the information about the global document count available. The decision if a term is added to a candidate list depends only on the order computed on the shard using local shard frequencies. The `min_doc_count` criterion is only applied after merging local terms statistics of all shards. In a way the decision to add the term as a candidate is made without being very _certain_ about if the term will actually reach the required `min_doc_count`. This might cause many (globally) high frequent terms to be missing in the final result if low frequent terms populated the candidate lists. To avoid this, the `shard_size` parameter can be increased to allow more candidate terms on the shards. However, this increases memory consumption and network traffic. -coming[1.2.0] `shard_min_doc_count` parameter +added[1.2.0] `shard_min_doc_count` parameter The parameter `shard_min_doc_count` regulates the _certainty_ a shard has if the term should actually be added to the candidate list or not with respect to the `min_doc_count`. Terms will only be considered if their local shard frequency within the set is higher than the `shard_min_doc_count`. If your dictionary contains many low frequent terms and you are not interested in those (for example misspellings), then you can set the `shard_min_doc_count` parameter to filter out candidate terms on a shard level that will with a resonable certainty not reach the required `min_doc_count` even after merging the local counts. `shard_min_doc_count` is set to `0` per default and has no effect unless you explicitly set it. @@ -322,7 +322,7 @@ http://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html#UNIX_LINES ==== Execution hint -coming[1.2.0] The `global_ordinals` execution mode +added[1.2.0] The `global_ordinals` execution mode There are three mechanisms by which terms aggregations can be executed: either by using field values directly in order to aggregate data per-bucket (`map`), by using ordinals of the field values instead of the values themselves (`ordinals`) or by using global diff --git a/docs/reference/search/suggesters/context-suggest.asciidoc b/docs/reference/search/suggesters/context-suggest.asciidoc index baa289b16e9..c110b8ea692 100644 --- a/docs/reference/search/suggesters/context-suggest.asciidoc +++ b/docs/reference/search/suggesters/context-suggest.asciidoc @@ -1,7 +1,7 @@ [[suggester-context]] === Context Suggester -coming[1.2.0] +added[1.2.0] The context suggester is an extension to the suggest API of Elasticsearch. Namely the suggester system provides a very fast way of searching documents by handling these