From 6b0e25408f9e1ddb731d8e82fd24a848f2d18b94 Mon Sep 17 00:00:00 2001 From: Fanit Kolchina Date: Fri, 7 Apr 2023 13:21:06 -0400 Subject: [PATCH 01/10] Add flat object field type Signed-off-by: Fanit Kolchina --- _field-types/flat-object.md | 177 ++++++++++++++++++++++++++++++++++++ _field-types/index.md | 2 +- 2 files changed, 178 insertions(+), 1 deletion(-) create mode 100644 _field-types/flat-object.md diff --git a/_field-types/flat-object.md b/_field-types/flat-object.md new file mode 100644 index 0000000000..d050596b55 --- /dev/null +++ b/_field-types/flat-object.md @@ -0,0 +1,177 @@ +--- +layout: default +title: Flat object +nav_order: 43 +has_children: false +parent: Object field types +grand_parent: Supported field types +--- + +# Flat object field type + +In OpenSearch, you don't have to specify a mapping before indexing documents. If you don't specify a mapping, OpenSearch uses [dynamic mapping]({{site.url}}{{site.baseurl}}/field-types/mappings#dynamic-mapping) to map every field and its subfields in the document automatically. When you ingest documents such as logs, you may not know every field's subfield name and type in advance. In this case, dynamically mapping all new subfields can quickly lead to a "mapping explosion", where the growing number of fields may degrade the performance of your cluster. + +Flat object solves this problem by not indexing the field itself or its subfields. Instead, for any JSON object, the values of all subfields and their paths are stored in two string fields. Subfields within the JSON are accessible using standard dot path notation but are not indexed for fast lookup. + +Flat objects provide the following advantages: + +- Efficient reads: Fetching performance is similar to that of a keyword field. +- Memory efficiency: Storing the entire complex JSON object in one field without indexing all its subfields reduces the number of fields in an index. +- Space efficiency: OpenSearch does not create an inverted index for flat objects, thereby saving space. +- Compatibility for migration: You can migrate your data from systems that support similar flat types to OpenSearch. + +Mapping a field as flat object applies when a field and its subfields are mostly read and not used as a search criteria because the subfields are not indexed. Flat objects are useful for objects with a large number of fields or when you don't know the keys in advance. + +Flat objects support: + +- Exact match queries. +- Textual sorting. +- Aggregations of subfields using the dot notation. +- Filtering by subfields. + +Searching for a specific value of a nested field in a document may be inefficient because it may require a full scan of the index, which is an expensive operation. +{: .note} + +Flat objects do not support: + +- Type-specific parsing. +- Numerical operations, such as numerical comparison and numerical sorting. +- Text analysis. +- Highlighting. + +## Supported queries + +The flat object field type supports the following queries: + +- [Term]({{site.url}}{{site.baseurl}}/query-dsl/query-dsl/term#term) +- [Terms]({{site.url}}{{site.baseurl}}/query-dsl/query-dsl/term#terms) +- [Terms set]({{site.url}}{{site.baseurl}}/query-dsl/query-dsl/term#terms-set) +- [Prefix]({{site.url}}{{site.baseurl}}/query-dsl/query-dsl/term#prefix) +- [Range]({{site.url}}{{site.baseurl}}/query-dsl/query-dsl/term#range) +- [Match]({{site.url}}{{site.baseurl}}/query-dsl/query-dsl/full-text/index#match) +- [Multi-match]({{site.url}}{{site.baseurl}}/query-dsl/query-dsl/full-text/index#multi-match) +- [Query string]({{site.url}}{{site.baseurl}}/query-dsl/query-dsl/full-text/index#query-string) +- [Simple query string]({{site.url}}{{site.baseurl}}/query-dsl/query-dsl/full-text/index#simple-query-string) +- [Exists]({{site.url}}{{site.baseurl}}/query-dsl/query-dsl/term#exists) + +## Limitations + +The following limitations apply to flat objects in the 2.7 release: + +- Flat objects do not support open parameters. +- Painless scripting and wildcard queries are not supported for retrieving values of subfields. + +This functionality is planned for a future release. + +## Example + +The following example illustrates mapping a field as a flat object, indexing documents with flat object fields, and searching for leaf values of the flat object in those documents. + +First, create a mapping for your index, where `issue` is of type `flat_object`: + +```json +PUT /test-index/ +{ + "mappings": { + "properties": { + "issue": { + "type": "flat_object" + } + } + } +} +``` +{% include copy-curl.html %} + +Next, index two documents with flat object fields: + +```json +PUT /test-index/_doc/1 +{ + "issue": { + "number": "123456", + "labels": { + "version": "2.1", + "backport": [ + "2.0", + "1.3" + ], + "category": { + "type": "API", + "level": "enhancement" + } + } + } +} +``` +{% include copy-curl.html %} + +```json +PUT /test-index/_doc/2 +{ + "issue": { + "number": "123457", + "labels": { + "version": "2.2", + "category": { + "type": "API", + "level": "bug" + } + } + } +} +``` +{% include copy-curl.html %} + +To search for a leaf value of the flat object, use a POST request and provide the value's path in dot notation. The following request searches for all issues labeled as bugs: + +```json +POST /test-index/_search +{ + "query": { + "match": {"issue.labels.category.level": "bug"} + } +} +``` +{% include copy-curl.html %} + +The response contains document 2: + +```json +{ + "took": 1, + "timed_out": false, + "_shards": { + "total": 1, + "successful": 1, + "skipped": 0, + "failed": 0 + }, + "hits": { + "total": { + "value": 1, + "relation": "eq" + }, + "max_score": 1.0303539, + "hits": [ + { + "_index": "test-index", + "_id": "2", + "_score": 1.0303539, + "_source": { + "issue": { + "number": "123457", + "labels": { + "version": "2.2", + "category": { + "type": "API", + "level": "bug" + } + } + } + } + } + ] + } +} +``` \ No newline at end of file diff --git a/_field-types/index.md b/_field-types/index.md index cca833a548..ee7488707c 100644 --- a/_field-types/index.md +++ b/_field-types/index.md @@ -22,7 +22,7 @@ Field data type | Description [`date`]({{site.url}}{{site.baseurl}}/opensearch/supported-field-types/date/) | A date value as a formatted string, a long value, or an integer. [`ip`]({{site.url}}{{site.baseurl}}/opensearch/supported-field-types/ip/) | An IP address in IPv4 or IPv6 format. [Range]({{site.url}}{{site.baseurl}}/opensearch/supported-field-types/range/) | `integer_range`, `long_range`,`double_range`, `float_range`, `date_range`,`ip_range`. -[Object]({{site.url}}{{site.baseurl}}/opensearch/supported-field-types/object/) | `object`, `nested`, `join`. +[Object]({{site.url}}{{site.baseurl}}/opensearch/supported-field-types/object/) | `object`, `nested`, `flat_object`, `join`. String | [`keyword`]({{site.url}}{{site.baseurl}}/opensearch/supported-field-types/keyword/), [`text`]({{site.url}}{{site.baseurl}}/opensearch/supported-field-types/text/), [`token_count`]({{site.url}}{{site.baseurl}}/opensearch/supported-field-types/token-count/). [Autocomplete]({{site.url}}{{site.baseurl}}/opensearch/supported-field-types/autocomplete/) | `completion`, `search_as_you_type`. [Geographic]({{site.url}}{{site.baseurl}}/opensearch/supported-field-types/geographic/) | `geo_point`, `geo_shape`. From 86a128390a65131c30b8b80a83b6dbb05547db41 Mon Sep 17 00:00:00 2001 From: Fanit Kolchina Date: Fri, 7 Apr 2023 15:04:53 -0400 Subject: [PATCH 02/10] Adds more examples and notes Signed-off-by: Fanit Kolchina --- _field-types/flat-object.md | 74 +++++++++++++++++++++++++++++-------- 1 file changed, 59 insertions(+), 15 deletions(-) diff --git a/_field-types/flat-object.md b/_field-types/flat-object.md index d050596b55..77fc841dc4 100644 --- a/_field-types/flat-object.md +++ b/_field-types/flat-object.md @@ -13,6 +13,9 @@ In OpenSearch, you don't have to specify a mapping before indexing documents. If Flat object solves this problem by not indexing the field itself or its subfields. Instead, for any JSON object, the values of all subfields and their paths are stored in two string fields. Subfields within the JSON are accessible using standard dot path notation but are not indexed for fast lookup. +The maximum field path length in the dot notation is 224 − 1. +{: .note} + Flat objects provide the following advantages: - Efficient reads: Fetching performance is similar to that of a keyword field. @@ -26,7 +29,7 @@ Flat objects support: - Exact match queries. - Textual sorting. -- Aggregations of subfields using the dot notation. +- Aggregations of subfields using dot notation. - Filtering by subfields. Searching for a specific value of a nested field in a document may be inefficient because it may require a full scan of the index, which is an expensive operation. @@ -43,16 +46,16 @@ Flat objects do not support: The flat object field type supports the following queries: -- [Term]({{site.url}}{{site.baseurl}}/query-dsl/query-dsl/term#term) -- [Terms]({{site.url}}{{site.baseurl}}/query-dsl/query-dsl/term#terms) -- [Terms set]({{site.url}}{{site.baseurl}}/query-dsl/query-dsl/term#terms-set) -- [Prefix]({{site.url}}{{site.baseurl}}/query-dsl/query-dsl/term#prefix) -- [Range]({{site.url}}{{site.baseurl}}/query-dsl/query-dsl/term#range) -- [Match]({{site.url}}{{site.baseurl}}/query-dsl/query-dsl/full-text/index#match) -- [Multi-match]({{site.url}}{{site.baseurl}}/query-dsl/query-dsl/full-text/index#multi-match) -- [Query string]({{site.url}}{{site.baseurl}}/query-dsl/query-dsl/full-text/index#query-string) -- [Simple query string]({{site.url}}{{site.baseurl}}/query-dsl/query-dsl/full-text/index#simple-query-string) -- [Exists]({{site.url}}{{site.baseurl}}/query-dsl/query-dsl/term#exists) +- [Term]({{site.url}}{{site.baseurl}}/query-dsl/term#term) +- [Terms]({{site.url}}{{site.baseurl}}/query-dsl/term#terms) +- [Terms set]({{site.url}}{{site.baseurl}}/query-dsl/term#terms-set) +- [Prefix]({{site.url}}{{site.baseurl}}/query-dsl/term#prefix) +- [Range]({{site.url}}{{site.baseurl}}/query-dsl/term#range) +- [Match]({{site.url}}{{site.baseurl}}/query-dsl/full-text/#match) +- [Multi-match]({{site.url}}{{site.baseurl}}/query-dsl/full-text/#multi-match) +- [Query string]({{site.url}}{{site.baseurl}}/query-dsl/full-text/#query-string) +- [Simple query string]({{site.url}}{{site.baseurl}}/query-dsl/full-text/#simple-query-string) +- [Exists]({{site.url}}{{site.baseurl}}/query-dsl/term#exists) ## Limitations @@ -63,10 +66,13 @@ The following limitations apply to flat objects in the 2.7 release: This functionality is planned for a future release. -## Example +## Using flat objects The following example illustrates mapping a field as a flat object, indexing documents with flat object fields, and searching for leaf values of the flat object in those documents. +Only root fields of a document can be defined as a flat objects. You cannot define an object that is part of another JSON object as a flat object because when a flat object it is flattened to a string, the nested architecture of the leaves is lost. +{: .note} + First, create a mapping for your index, where `issue` is of type `flat_object`: ```json @@ -123,7 +129,18 @@ PUT /test-index/_doc/2 ``` {% include copy-curl.html %} -To search for a leaf value of the flat object, use a POST request and provide the value's path in dot notation. The following request searches for all issues labeled as bugs: +To search for a leaf value of the flat object, use a POST request. Even if you don't know the field names, you can search for a leaf value in the entire flat object. For example, the following request searches for all issues labeled as bugs: + +```json +POST /test-index/_search +{ + "query": { + "match": {"issue": "bug"} + } +} +``` + +Alternatively, if you know the subfield name in which to search, provide the field's path in dot notation: ```json POST /test-index/_search @@ -135,7 +152,7 @@ POST /test-index/_search ``` {% include copy-curl.html %} -The response contains document 2: +In both previous cases, the response is the same and contains document 2: ```json { @@ -174,4 +191,31 @@ The response contains document 2: ] } } -``` \ No newline at end of file +``` + +Using a prefix query, you can search for all issues for the versions that start with `2.`: + +```json +POST /test-index/_search +{ + "query": { + "prefix": {"issue.labels.version": "2."} + } +} +``` + +With a range query, you can search for all issues for versions 2.0--2.1: + +```json +POST /test-index/_search +{ + "query": { + "range": { + "issue": { + "gte": "2.0", + "lte": "2.1" + } + } + } +} +``` From 22d87e8e71d22da321af0d25f6659990ac522485 Mon Sep 17 00:00:00 2001 From: Fanit Kolchina Date: Fri, 7 Apr 2023 20:36:37 -0400 Subject: [PATCH 03/10] Implemented tech review comments Signed-off-by: Fanit Kolchina --- _field-types/flat-object.md | 15 ++++++--------- 1 file changed, 6 insertions(+), 9 deletions(-) diff --git a/_field-types/flat-object.md b/_field-types/flat-object.md index 77fc841dc4..cb288e4556 100644 --- a/_field-types/flat-object.md +++ b/_field-types/flat-object.md @@ -11,26 +11,21 @@ grand_parent: Supported field types In OpenSearch, you don't have to specify a mapping before indexing documents. If you don't specify a mapping, OpenSearch uses [dynamic mapping]({{site.url}}{{site.baseurl}}/field-types/mappings#dynamic-mapping) to map every field and its subfields in the document automatically. When you ingest documents such as logs, you may not know every field's subfield name and type in advance. In this case, dynamically mapping all new subfields can quickly lead to a "mapping explosion", where the growing number of fields may degrade the performance of your cluster. -Flat object solves this problem by not indexing the field itself or its subfields. Instead, for any JSON object, the values of all subfields and their paths are stored in two string fields. Subfields within the JSON are accessible using standard dot path notation but are not indexed for fast lookup. +Flat object solves this problem by treating the entire JSON object as a string. Subfields within the JSON object are accessible using standard dot path notation but they are not indexed for fast lookup. -The maximum field path length in the dot notation is 224 − 1. +The maximum field value length in the dot notation is 224 − 1. {: .note} Flat objects provide the following advantages: - Efficient reads: Fetching performance is similar to that of a keyword field. - Memory efficiency: Storing the entire complex JSON object in one field without indexing all its subfields reduces the number of fields in an index. -- Space efficiency: OpenSearch does not create an inverted index for flat objects, thereby saving space. +- Space efficiency: OpenSearch does not create an inverted index for subfields in flat objects, thereby saving space. - Compatibility for migration: You can migrate your data from systems that support similar flat types to OpenSearch. Mapping a field as flat object applies when a field and its subfields are mostly read and not used as a search criteria because the subfields are not indexed. Flat objects are useful for objects with a large number of fields or when you don't know the keys in advance. -Flat objects support: - -- Exact match queries. -- Textual sorting. -- Aggregations of subfields using dot notation. -- Filtering by subfields. +Flat objects support exact match queries with and without dot path. For a complete list of supported query types, see [Supported queries](#supported-queries). Searching for a specific value of a nested field in a document may be inefficient because it may require a full scan of the index, which is an expensive operation. {: .note} @@ -41,6 +36,8 @@ Flat objects do not support: - Numerical operations, such as numerical comparison and numerical sorting. - Text analysis. - Highlighting. +- Aggregations of subfields using dot notation. +- Filtering by subfields. ## Supported queries From dc94b110722d60bb6f35a78b6c04ae5f6db68d22 Mon Sep 17 00:00:00 2001 From: Fanit Kolchina Date: Fri, 7 Apr 2023 20:39:22 -0400 Subject: [PATCH 04/10] Update page order Signed-off-by: Fanit Kolchina --- _field-types/join.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_field-types/join.md b/_field-types/join.md index bd14f25082..806c7eb342 100644 --- a/_field-types/join.md +++ b/_field-types/join.md @@ -1,7 +1,7 @@ --- layout: default title: Join -nav_order: 43 +nav_order: 44 has_children: false parent: Object field types grand_parent: Supported field types From 3d368daa4331ba9c7d835a6a5791ac8b1d9439a3 Mon Sep 17 00:00:00 2001 From: Fanit Kolchina Date: Thu, 13 Apr 2023 18:14:12 -0400 Subject: [PATCH 05/10] Implemented tech review feedback Signed-off-by: Fanit Kolchina --- _field-types/flat-object.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/_field-types/flat-object.md b/_field-types/flat-object.md index cb288e4556..60d0e5a228 100644 --- a/_field-types/flat-object.md +++ b/_field-types/flat-object.md @@ -63,11 +63,11 @@ The following limitations apply to flat objects in the 2.7 release: This functionality is planned for a future release. -## Using flat objects +## Using flat object The following example illustrates mapping a field as a flat object, indexing documents with flat object fields, and searching for leaf values of the flat object in those documents. -Only root fields of a document can be defined as a flat objects. You cannot define an object that is part of another JSON object as a flat object because when a flat object it is flattened to a string, the nested architecture of the leaves is lost. +Only the root field of a document can be defined as a flat object. You cannot define an object that is part of another JSON object as a flat object because when a flat object it is flattened to a string, the nested architecture of the leaves is lost. {: .note} First, create a mapping for your index, where `issue` is of type `flat_object`: From 0dcc1fbccc7e4b3510084937f6e50a0bc9551e80 Mon Sep 17 00:00:00 2001 From: kolchfa-aws <105444904+kolchfa-aws@users.noreply.github.com> Date: Tue, 18 Apr 2023 09:13:37 -0400 Subject: [PATCH 06/10] Apply suggestions from code review Co-authored-by: Melissa Vagi --- _field-types/flat-object.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/_field-types/flat-object.md b/_field-types/flat-object.md index 60d0e5a228..59ade1d60d 100644 --- a/_field-types/flat-object.md +++ b/_field-types/flat-object.md @@ -9,9 +9,9 @@ grand_parent: Supported field types # Flat object field type -In OpenSearch, you don't have to specify a mapping before indexing documents. If you don't specify a mapping, OpenSearch uses [dynamic mapping]({{site.url}}{{site.baseurl}}/field-types/mappings#dynamic-mapping) to map every field and its subfields in the document automatically. When you ingest documents such as logs, you may not know every field's subfield name and type in advance. In this case, dynamically mapping all new subfields can quickly lead to a "mapping explosion", where the growing number of fields may degrade the performance of your cluster. +In OpenSearch, you don't have to specify a mapping before indexing documents. If you don't specify a mapping, OpenSearch uses [dynamic mapping]({{site.url}}{{site.baseurl}}/field-types/mappings#dynamic-mapping) to map every field and its subfields in the document automatically. When you ingest documents such as logs, you may not know every field's subfield name and type in advance. In this case, dynamically mapping all new subfields can quickly lead to a "mapping explosion," where the growing number of fields may degrade the performance of your cluster. -Flat object solves this problem by treating the entire JSON object as a string. Subfields within the JSON object are accessible using standard dot path notation but they are not indexed for fast lookup. +Flat object solves this problem by treating the entire JSON object as a string. Subfields within the JSON object are accessible using standard dot path notation, but they are not indexed for fast lookup. The maximum field value length in the dot notation is 224 − 1. {: .note} @@ -25,7 +25,7 @@ Flat objects provide the following advantages: Mapping a field as flat object applies when a field and its subfields are mostly read and not used as a search criteria because the subfields are not indexed. Flat objects are useful for objects with a large number of fields or when you don't know the keys in advance. -Flat objects support exact match queries with and without dot path. For a complete list of supported query types, see [Supported queries](#supported-queries). +Flat objects support exact match queries with and without dot path notation. For a complete list of supported query types, see [Supported queries](#supported-queries). Searching for a specific value of a nested field in a document may be inefficient because it may require a full scan of the index, which is an expensive operation. {: .note} @@ -67,7 +67,7 @@ This functionality is planned for a future release. The following example illustrates mapping a field as a flat object, indexing documents with flat object fields, and searching for leaf values of the flat object in those documents. -Only the root field of a document can be defined as a flat object. You cannot define an object that is part of another JSON object as a flat object because when a flat object it is flattened to a string, the nested architecture of the leaves is lost. +Only the root field of a document can be defined as a flat object. You cannot define an object that is part of another JSON object as a flat object because when a flat object is flattened to a string, the nested architecture of the leaves is lost. {: .note} First, create a mapping for your index, where `issue` is of type `flat_object`: From 28957b8232965d84038d722d653e5d1a63c4a916 Mon Sep 17 00:00:00 2001 From: Fanit Kolchina Date: Tue, 18 Apr 2023 12:07:23 -0400 Subject: [PATCH 07/10] More doc review comments Signed-off-by: Fanit Kolchina --- _field-types/flat-object.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/_field-types/flat-object.md b/_field-types/flat-object.md index 59ade1d60d..47425828a9 100644 --- a/_field-types/flat-object.md +++ b/_field-types/flat-object.md @@ -11,19 +11,19 @@ grand_parent: Supported field types In OpenSearch, you don't have to specify a mapping before indexing documents. If you don't specify a mapping, OpenSearch uses [dynamic mapping]({{site.url}}{{site.baseurl}}/field-types/mappings#dynamic-mapping) to map every field and its subfields in the document automatically. When you ingest documents such as logs, you may not know every field's subfield name and type in advance. In this case, dynamically mapping all new subfields can quickly lead to a "mapping explosion," where the growing number of fields may degrade the performance of your cluster. -Flat object solves this problem by treating the entire JSON object as a string. Subfields within the JSON object are accessible using standard dot path notation, but they are not indexed for fast lookup. +The flat object field type solves this problem by treating the entire JSON object as a string. Subfields within the JSON object are accessible using standard dot path notation, but they are not indexed for fast lookup. The maximum field value length in the dot notation is 224 − 1. {: .note} -Flat objects provide the following advantages: +The flat object field type provides the following advantages: - Efficient reads: Fetching performance is similar to that of a keyword field. - Memory efficiency: Storing the entire complex JSON object in one field without indexing all its subfields reduces the number of fields in an index. - Space efficiency: OpenSearch does not create an inverted index for subfields in flat objects, thereby saving space. - Compatibility for migration: You can migrate your data from systems that support similar flat types to OpenSearch. -Mapping a field as flat object applies when a field and its subfields are mostly read and not used as a search criteria because the subfields are not indexed. Flat objects are useful for objects with a large number of fields or when you don't know the keys in advance. +Mapping a field as a flat object applies when a field and its subfields are mostly read and not used as a search criteria because the subfields are not indexed. Flat objects are useful for objects with a large number of fields or when you don't know the keys in advance. Flat objects support exact match queries with and without dot path notation. For a complete list of supported query types, see [Supported queries](#supported-queries). From 4f0d1bf3176b6b37112f16808e965e3b7edef17c Mon Sep 17 00:00:00 2001 From: kolchfa-aws <105444904+kolchfa-aws@users.noreply.github.com> Date: Tue, 18 Apr 2023 14:15:31 -0400 Subject: [PATCH 08/10] Apply suggestions from code review Co-authored-by: Nathan Bower --- _field-types/flat-object.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/_field-types/flat-object.md b/_field-types/flat-object.md index 47425828a9..37d38e0d7a 100644 --- a/_field-types/flat-object.md +++ b/_field-types/flat-object.md @@ -16,10 +16,10 @@ The flat object field type solves this problem by treating the entire JSON objec The maximum field value length in the dot notation is 224 − 1. {: .note} -The flat object field type provides the following advantages: +The flat object field type provides the following benefits: - Efficient reads: Fetching performance is similar to that of a keyword field. -- Memory efficiency: Storing the entire complex JSON object in one field without indexing all its subfields reduces the number of fields in an index. +- Memory efficiency: Storing the entire complex JSON object in one field without indexing all of its subfields reduces the number of fields in an index. - Space efficiency: OpenSearch does not create an inverted index for subfields in flat objects, thereby saving space. - Compatibility for migration: You can migrate your data from systems that support similar flat types to OpenSearch. @@ -27,13 +27,13 @@ Mapping a field as a flat object applies when a field and its subfields are most Flat objects support exact match queries with and without dot path notation. For a complete list of supported query types, see [Supported queries](#supported-queries). -Searching for a specific value of a nested field in a document may be inefficient because it may require a full scan of the index, which is an expensive operation. +Searching for a specific value of a nested field in a document may be inefficient because it may require a full scan of the index, which can be an expensive operation. {: .note} Flat objects do not support: - Type-specific parsing. -- Numerical operations, such as numerical comparison and numerical sorting. +- Numerical operations, such as numerical comparison or numerical sorting. - Text analysis. - Highlighting. - Aggregations of subfields using dot notation. @@ -56,7 +56,7 @@ The flat object field type supports the following queries: ## Limitations -The following limitations apply to flat objects in the 2.7 release: +The following limitations apply to flat objects in OpenSearch 2.7: - Flat objects do not support open parameters. - Painless scripting and wildcard queries are not supported for retrieving values of subfields. @@ -149,7 +149,7 @@ POST /test-index/_search ``` {% include copy-curl.html %} -In both previous cases, the response is the same and contains document 2: +In both cases, the response is the same and contains document 2: ```json { From 12556ce66c68aeb40bdb8d366b65878658e177cb Mon Sep 17 00:00:00 2001 From: Fanit Kolchina Date: Tue, 18 Apr 2023 14:16:44 -0400 Subject: [PATCH 09/10] Implemented the last editorial comment Signed-off-by: Fanit Kolchina --- _field-types/flat-object.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_field-types/flat-object.md b/_field-types/flat-object.md index 37d38e0d7a..2d748391f6 100644 --- a/_field-types/flat-object.md +++ b/_field-types/flat-object.md @@ -23,7 +23,7 @@ The flat object field type provides the following benefits: - Space efficiency: OpenSearch does not create an inverted index for subfields in flat objects, thereby saving space. - Compatibility for migration: You can migrate your data from systems that support similar flat types to OpenSearch. -Mapping a field as a flat object applies when a field and its subfields are mostly read and not used as a search criteria because the subfields are not indexed. Flat objects are useful for objects with a large number of fields or when you don't know the keys in advance. +Mapping a field as a flat object applies when a field and its subfields are mostly read and not used as search criteria because the subfields are not indexed. Flat objects are useful for objects with a large number of fields or when you don't know the keys in advance. Flat objects support exact match queries with and without dot path notation. For a complete list of supported query types, see [Supported queries](#supported-queries). From 8c9a03357e14eec901a99c1e946b35baf7996852 Mon Sep 17 00:00:00 2001 From: Fanit Kolchina Date: Fri, 21 Apr 2023 17:33:02 -0400 Subject: [PATCH 10/10] Changed POST to GET Signed-off-by: Fanit Kolchina --- _field-types/flat-object.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/_field-types/flat-object.md b/_field-types/flat-object.md index 2d748391f6..7adc25994e 100644 --- a/_field-types/flat-object.md +++ b/_field-types/flat-object.md @@ -126,10 +126,10 @@ PUT /test-index/_doc/2 ``` {% include copy-curl.html %} -To search for a leaf value of the flat object, use a POST request. Even if you don't know the field names, you can search for a leaf value in the entire flat object. For example, the following request searches for all issues labeled as bugs: +To search for a leaf value of the flat object, use either a GET or a POST request. Even if you don't know the field names, you can search for a leaf value in the entire flat object. For example, the following request searches for all issues labeled as bugs: ```json -POST /test-index/_search +GET /test-index/_search { "query": { "match": {"issue": "bug"} @@ -140,7 +140,7 @@ POST /test-index/_search Alternatively, if you know the subfield name in which to search, provide the field's path in dot notation: ```json -POST /test-index/_search +GET /test-index/_search { "query": { "match": {"issue.labels.category.level": "bug"} @@ -193,7 +193,7 @@ In both cases, the response is the same and contains document 2: Using a prefix query, you can search for all issues for the versions that start with `2.`: ```json -POST /test-index/_search +GET /test-index/_search { "query": { "prefix": {"issue.labels.version": "2."} @@ -204,7 +204,7 @@ POST /test-index/_search With a range query, you can search for all issues for versions 2.0--2.1: ```json -POST /test-index/_search +GET /test-index/_search { "query": { "range": {