Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add flat object field type #3714

Merged
merged 10 commits into from
May 2, 2023
Merged

Add flat object field type #3714

Changes from 1 commit
Commits
Show all changes
10 commits
Select commit Hold shift + click to select a range
6b0e254
Add flat object field type
kolchfa-aws Apr 7, 2023
86a1283
Adds more examples and notes
kolchfa-aws Apr 7, 2023
22d87e8
Implemented tech review comments
kolchfa-aws Apr 8, 2023
dc94b11
Update page order
kolchfa-aws Apr 8, 2023
3d368da
Implemented tech review feedback
kolchfa-aws Apr 13, 2023
0dcc1fb
Apply suggestions from code review
kolchfa-aws Apr 18, 2023
28957b8
More doc review comments
kolchfa-aws Apr 18, 2023
4f0d1bf
Apply suggestions from code review
kolchfa-aws Apr 18, 2023
12556ce
Implemented the last editorial comment
kolchfa-aws Apr 18, 2023
8c9a033
Changed POST to GET
kolchfa-aws Apr 21, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 5 additions & 5 deletions _field-types/flat-object.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why changing the request command from POST to GET? the HTTP POST command is used for queries that have a request body, such as search queries.

The request body can be large: search queries can be complex. When using the HTTP GET command, the URL has a limited length, and if the request body is too large, it may not fit in the URL. By using the HTTP POST command, the request body can be sent separately in the request payload, and there is no limit to its size.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mingshl Changed as per @macohen.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mingshl GET is the standard for searching in OpenSearch. it was surprising to me, too, that you can send a payload like you do with POST in a GET. Take a look at https://opensearch.org/docs/latest/aggregations/metric-agg/ and other query docs. the HTTP spec says we're putting meaning where it shouldn't be, but it doesn't disallow it: "A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request." https://datatracker.ietf.org/doc/html/rfc7231#section-4.3.1

{
"query": {
"match": {"issue": "bug"}
Expand All @@ -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:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We use the verbiage "dot path notation" in preceding sections. Should we be consistent here?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This sentence already has the word "path" so I think we don't need to specify it again. Let's ask @natebower

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm fine with it as is as long as both "dot path notation" and "dot notation" are commonly understood as referring to the same thing.


```json
POST /test-index/_search
GET /test-index/_search
{
"query": {
"match": {"issue.labels.category.level": "bug"}
Expand Down Expand Up @@ -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."}
Expand All @@ -204,7 +204,7 @@ POST /test-index/_search
With a range query, you can search for all issues for versions 2.0--2.1:
natebower marked this conversation as resolved.
Show resolved Hide resolved

```json
POST /test-index/_search
GET /test-index/_search
{
"query": {
"range": {
Expand Down