Skip to content

Conversation

@dnhatn
Copy link
Member

@dnhatn dnhatn commented Mar 13, 2021

If a search after request targets multiple indices and some of its sort field has type date in one index but date_nanos in other indices, then Elasticsearch won't interpret the search_after parameter correctly in every target index. The sort value of a date field by default is a long of milliseconds since the epoch while a date_nanos field is a long of nanoseconds.

This commit introduces the format parameter in the sort field so a sort value of a date or date_nanos will be formatted using a date format in a search response.

The below example illustrates how to use this new parameter.

{
    "query": {
        "match_all": {}
    },
    "sort": [
        {
            "timestamp": { 
                "order": "asc", 
                "format": "strict_date_optional_time_nanos" 
           }
        }
    ]
}
{
    "query": {
        "match_all": {}
    },
    "sort": [
        {
            "timestamp": { 
                "order": "asc",
                "format": "strict_date_optional_time_nanos" 
            }
        }
    ],
    "search_after": [
        "2015-01-01T12:10:30.123456789Z" // in `strict_date_optional_time_nanos` format 
    ]
}

Closes #69192

@dnhatn dnhatn force-pushed the format-sort-values branch from 1093423 to c1d7f75 Compare March 13, 2021 19:00
@dnhatn dnhatn marked this pull request as ready for review March 13, 2021 19:01
@dnhatn dnhatn added the :Search/Search Search-related issues that do not fall into other categories label Mar 13, 2021
@elasticmachine elasticmachine added the Team:Search Meta label for search team label Mar 13, 2021
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-search (Team:Search)

@dnhatn dnhatn added >enhancement v8.0.0 v7.13.0 and removed Team:Search Meta label for search team labels Mar 13, 2021
@dnhatn
Copy link
Member Author

dnhatn commented Mar 13, 2021

@jrodewig Would you mind taking a look at the doc changes? Thank you!

@jrodewig jrodewig self-requested a review March 13, 2021 23:00
Copy link
Contributor

@jrodewig jrodewig left a comment

Choose a reason for hiding this comment

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

LGTM. Thanks @dnhatn!

I left a couple of non-blocking suggestions that you can ignore if wanted.

@dnhatn
Copy link
Member Author

dnhatn commented Mar 15, 2021

@jrodewig Thanks for the quick review. I've integrated your suggestions. Both of them are great 👍.

@dnhatn
Copy link
Member Author

dnhatn commented Mar 15, 2021

@elasticmachine update branch

Copy link
Contributor

@jimczi jimczi left a comment

Choose a reason for hiding this comment

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

I left one comment regarding the docs, LGTM otherwise.

Copy link
Contributor

@jrodewig jrodewig left a comment

Choose a reason for hiding this comment

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

Expanded docs LGTM. Thanks @dnhatn.


resp = client().prepareSearch("test")
.addSort(SortBuilders.fieldSort("start_date").setFormat("dd/MM/yyyy"))
.addSort(SortBuilders.fieldSort("end_date")) // it's okay as we use the default format, but the output does not format
Copy link
Contributor

@mayya-sharipova mayya-sharipova Mar 16, 2021

Choose a reason for hiding this comment

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

Isn't there a requirement that searchAfter formats and formats in Sort should match?

Or it is ok because "yyyy-MM-dd" is a default formant for end_date?

Copy link
Member Author

Choose a reason for hiding this comment

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

Or it is ok because "yyyy-MM-dd" is a default formant for end_date?

This is okay because end_date has the format yyyy-MM-dd. I reworded this comment in 9c537d5.

Isn't there a requirement that searchAfter formats and formats in Sort should match?

The formats (specified by sort) will try to parse the search_after parameters. If the parameters do not conform, then we will fail the request as a bad request.

Copy link
Contributor

Choose a reason for hiding this comment

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

thanks for the clarifications, Nhat

@dnhatn dnhatn requested a review from mayya-sharipova March 16, 2021 17:43
Copy link
Contributor

@mayya-sharipova mayya-sharipova left a comment

Choose a reason for hiding this comment

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

@dnhatn Thanks Nhat, excellent work! All the changes LGTM!

@dnhatn
Copy link
Member Author

dnhatn commented Mar 17, 2021

Thanks everyone :).

@dnhatn dnhatn merged commit 8b5aa84 into elastic:master Mar 17, 2021
@dnhatn dnhatn deleted the format-sort-values branch March 17, 2021 01:27
dnhatn added a commit to dnhatn/elasticsearch that referenced this pull request Mar 20, 2021
If a search after request targets multiple indices and some of its sort
field has type `date` in one index but `date_nanos` in other indices,
then Elasticsearch won't interpret the search_after parameter correctly
in every target index. The sort value of a date field by default is a
long of milliseconds since the epoch while a date_nanos field is a long
of nanoseconds.

This commit introduces the `format` parameter in the sort field so a
sort value of a date or date_nanos will be formatted using a date format
in a search response.

The below example illustrates how to use this new parameter.

```js
{
    "query": {
        "match_all": {}
    },
    "sort": [
        {
            "timestamp": {
                "order": "asc",
                "format": "strict_date_optional_time_nanos"
           }
        }
    ]
}
```

```js
{
    "query": {
        "match_all": {}
    },
    "sort": [
        {
            "timestamp": {
                "order": "asc",
                "format": "strict_date_optional_time_nanos"
            }
        }
    ],
    "search_after": [
        "2015-01-01T12:10:30.123456789Z" // in `strict_date_optional_time_nanos` format
    ]
}
```

Closes elastic#69192
dnhatn added a commit that referenced this pull request Mar 21, 2021
If a search after request targets multiple indices and some of its sort
field has type `date` in one index but `date_nanos` in other indices,
then Elasticsearch won't interpret the search_after parameter correctly
in every target index. The sort value of a date field by default is a
long of milliseconds since the epoch while a date_nanos field is a long
of nanoseconds.

This commit introduces the `format` parameter in the sort field so a
sort value of a date or date_nanos will be formatted using a date format
in a search response.

The below example illustrates how to use this new parameter.

```js
{
    "query": {
        "match_all": {}
    },
    "sort": [
        {
            "timestamp": {
                "order": "asc",
                "format": "strict_date_optional_time_nanos"
           }
        }
    ]
}
```

```js
{
    "query": {
        "match_all": {}
    },
    "sort": [
        {
            "timestamp": {
                "order": "asc",
                "format": "strict_date_optional_time_nanos"
            }
        }
    ],
    "search_after": [
        "2015-01-01T12:10:30.123456789Z" // in `strict_date_optional_time_nanos` format
    ]
}
```

Closes #69192
dnhatn added a commit that referenced this pull request Mar 21, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

>enhancement :Search/Search Search-related issues that do not fall into other categories v7.13.0 v8.0.0-alpha1

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Formatted sort values for search_after

6 participants