OpenSearch/docs/reference/sql/endpoints/translate.asciidoc
Andrei Stefan 2633d11eb7
Switch from using docvalue_fields to extracting values from _source (#44062) (#44804)
* Switch from using docvalue_fields to extracting values from _source
where applicable. Doing this means parsing the _source and handling the
numbers parsing just like Elasticsearch is doing it when it's indexing
a document.
* This also introduces a minor limitation: aliases type of fields that
are NOT part of a tree of sub-fields will not be able to be retrieved
anymore. field_caps API doesn't shed any light into a field being an
alias or not and at _source parsing time there is no way to know if a
root field is an alias or not. Fields of the type "a.b.c.alias" can be
extracted from docvalue_fields, only if the field they point to can be
extracted from docvalue_fields. Also, not all fields in a hierarchy of
fields can be evaluated to being an alias.

(cherry picked from commit 8bf8a055e38f00df5f49c8d97f632f69d6e00c2c)
2019-07-25 10:02:41 +03:00

60 lines
1.4 KiB
Plaintext

[role="xpack"]
[testenv="basic"]
[[sql-translate]]
== SQL Translate API
The SQL Translate API accepts SQL in a JSON document and translates it
into native {es} queries. For example:
[source,js]
--------------------------------------------------
POST /_sql/translate
{
"query": "SELECT * FROM library ORDER BY page_count DESC",
"fetch_size": 10
}
--------------------------------------------------
// CONSOLE
// TEST[setup:library]
Which returns:
[source,js]
--------------------------------------------------
{
"size" : 10,
"docvalue_fields" : [
{
"field": "release_date",
"format": "epoch_millis"
}
],
"_source": {
"includes": [
"author",
"name",
"page_count"
],
"excludes": []
},
"sort" : [
{
"page_count" : {
"order" : "desc",
"missing" : "_first",
"unmapped_type" : "short"
}
}
]
}
--------------------------------------------------
// TESTRESPONSE
Which is the request that SQL will run to provide the results.
In this case, SQL will use the <<request-body-search-scroll,scroll>>
API. If the result contained an aggregation then SQL would use
the normal <<search-request-body,search>> API.
The request body accepts all of the <<sql-rest-fields,fields>> that
the <<sql-rest,SQL REST API>> accepts except `cursor`.