mirror of
https://github.com/elastic/elasticsearch.git
synced 2025-06-28 17:34:17 -04:00
002ed8d49d
* Fix error on sorting unsortable geo_point and cartesian_point Without a LIMIT the correct error worked, but with LIMIT it did not. This fix mimics the same error with LIMIT and adds tests for all three scenarios: * Without limit * With Limit * From row with limit * Update docs/changelog/106351.yaml * Add tests for geo_shape and cartesian_shape also * Updated changelog * Separate point and shape error messages * Move error to later so we get it only if geo field is actually used in sort. * Implemented planner check in Verifier instead This is a much better solution. * Revert previous solution * Also check non-field attributes so the same error is provided for ROW * Changed "can't" to "cannot" * Add unit tests for verifier error * Added sort limitations to documentation * Added unit tests for spatial fields in VerifierTests * Don't run the new yaml tests on older versions These tests mostly test the validation errors which were changed only in 8.14.0, so should not be tested in earlier versions. * Simplify check based on code review, skip duplicate forEachDown
216 lines
5.9 KiB
Text
216 lines
5.9 KiB
Text
[[esql-limitations]]
|
|
== {esql} limitations
|
|
|
|
++++
|
|
<titleabbrev>Limitations</titleabbrev>
|
|
++++
|
|
|
|
[discrete]
|
|
[[esql-max-rows]]
|
|
=== Result set size limit
|
|
|
|
By default, an {esql} query returns up to 1000 rows. You can increase the number
|
|
of rows up to 10,000 using the <<esql-limit>> command.
|
|
include::processing-commands/limit.asciidoc[tag=limitation]
|
|
|
|
[discrete]
|
|
[[esql-supported-types]]
|
|
=== Field types
|
|
|
|
[discrete]
|
|
==== Supported types
|
|
|
|
{esql} currently supports the following <<mapping-types,field types>>:
|
|
|
|
* `alias`
|
|
* `boolean`
|
|
* `date`
|
|
* `double` (`float`, `half_float`, `scaled_float` are represented as `double`)
|
|
* `ip`
|
|
* `keyword` family including `keyword`, `constant_keyword`, and `wildcard`
|
|
* `int` (`short` and `byte` are represented as `int`)
|
|
* `long`
|
|
* `null`
|
|
* `text`
|
|
* experimental:[] `unsigned_long`
|
|
* `version`
|
|
* Spatial types
|
|
** `geo_point`
|
|
** `geo_shape`
|
|
** `point`
|
|
** `shape`
|
|
|
|
[discrete]
|
|
==== Unsupported types
|
|
|
|
{esql} does not yet support the following field types:
|
|
|
|
* TSDB metrics
|
|
** `counter`
|
|
** `position`
|
|
** `aggregate_metric_double`
|
|
* Date/time
|
|
** `date_nanos`
|
|
** `date_range`
|
|
* Other types
|
|
** `binary`
|
|
** `completion`
|
|
** `dense_vector`
|
|
** `double_range`
|
|
** `flattened`
|
|
** `float_range`
|
|
** `histogram`
|
|
** `integer_range`
|
|
** `ip_range`
|
|
** `long_range`
|
|
** `nested`
|
|
** `rank_feature`
|
|
** `rank_features`
|
|
** `search_as_you_type`
|
|
|
|
Querying a column with an unsupported type returns an error. If a column with an
|
|
unsupported type is not explicitly used in a query, it is returned with `null`
|
|
values, with the exception of nested fields. Nested fields are not returned at
|
|
all.
|
|
|
|
[discrete]
|
|
==== Limitations on supported types
|
|
|
|
Some <<mapping-types,field types>> are not supported in all contexts:
|
|
|
|
* Spatial types are not supported in the <<esql-sort,SORT>> processing command.
|
|
Specifying a column of one of these types as a sort parameter will result in an error:
|
|
** `geo_point`
|
|
** `geo_shape`
|
|
** `cartesian_point`
|
|
** `cartesian_shape`
|
|
|
|
[discrete]
|
|
[[esql-_source-availability]]
|
|
=== _source availability
|
|
|
|
{esql} does not support configurations where the
|
|
<<mapping-source-field,_source field>> is <<disable-source-field,disabled>>.
|
|
|
|
experimental:[] {esql}'s support for <<synthetic-source,synthetic `_source`>>
|
|
is currently experimental.
|
|
|
|
[discrete]
|
|
[[esql-limitations-full-text-search]]
|
|
=== Full-text search is not supported
|
|
|
|
Because of <<esql-limitations-text-fields,the way {esql} treats `text` values>>,
|
|
full-text search is not yet supported. Queries on `text` fields are like queries
|
|
on `keyword` fields: they are case-sensitive and need to match the full string.
|
|
|
|
For example, after indexing a field of type `text` with the value `Elasticsearch
|
|
query language`, the following `WHERE` clause does not match because the `LIKE`
|
|
operator is case-sensitive:
|
|
[source,esql]
|
|
----
|
|
| WHERE field LIKE "elasticsearch query language"
|
|
----
|
|
|
|
The following `WHERE` clause does not match either, because the `LIKE` operator
|
|
tries to match the whole string:
|
|
[source,esql]
|
|
----
|
|
| WHERE field LIKE "Elasticsearch"
|
|
----
|
|
|
|
As a workaround, use wildcards and regular expressions. For example:
|
|
[source,esql]
|
|
----
|
|
| WHERE field RLIKE "[Ee]lasticsearch.*"
|
|
----
|
|
|
|
[discrete]
|
|
[[esql-limitations-text-fields]]
|
|
=== `text` fields behave like `keyword` fields
|
|
|
|
While {esql} supports <<text,`text`>> fields, {esql} does not treat these fields
|
|
like the Search API does. {esql} queries do not query or aggregate the
|
|
<<analysis,analyzed string>>. Instead, an {esql} query will try to get a `text`
|
|
field's subfield of the <<keyword,keyword family type>> and query/aggregate
|
|
that. If it's not possible to retrieve a `keyword` subfield, {esql} will get the
|
|
string from a document's `_source`. If the `_source` cannot be retrieved, for
|
|
example when using synthetic source, `null` is returned.
|
|
|
|
Note that {esql}'s retrieval of `keyword` subfields may have unexpected
|
|
consequences. An {esql} query on a `text` field is case-sensitive. Furthermore,
|
|
a subfield may have been mapped with a <<normalizer,normalizer>>, which can
|
|
transform the original string. Or it may have been mapped with <<ignore-above>>,
|
|
which can truncate the string. None of these mapping operations are applied to
|
|
an {esql} query, which may lead to false positives or negatives.
|
|
|
|
To avoid these issues, a best practice is to be explicit about the field that
|
|
you query, and query `keyword` sub-fields instead of `text` fields.
|
|
|
|
[discrete]
|
|
[[esql-tsdb]]
|
|
=== Time series data streams are not supported
|
|
|
|
{esql} does not support querying time series data streams (TSDS).
|
|
|
|
[discrete]
|
|
[[esql-limitations-date-math]]
|
|
=== Date math limitations
|
|
|
|
Date math expressions work well when the leftmost expression is a datetime, for
|
|
example:
|
|
[source,txt]
|
|
----
|
|
now() + 1 year - 2hour + ...
|
|
----
|
|
|
|
But using parentheses or putting the datetime to the right is not always supported yet. For example, the following expressions fail:
|
|
[source,txt]
|
|
----
|
|
1year + 2hour + now()
|
|
now() + (1year + 2hour)
|
|
----
|
|
|
|
Date math does not allow subtracting two datetimes, for example:
|
|
[source,txt]
|
|
----
|
|
now() - 2023-10-26
|
|
----
|
|
|
|
[discrete]
|
|
[[esql-limitations-enrich]]
|
|
=== Enrich limitations
|
|
|
|
include::esql-enrich-data.asciidoc[tag=limitations]
|
|
|
|
[discrete]
|
|
[[esql-limitations-dissect]]
|
|
=== Dissect limitations
|
|
|
|
include::esql-process-data-with-dissect-grok.asciidoc[tag=dissect-limitations]
|
|
|
|
[discrete]
|
|
[[esql-limitations-grok]]
|
|
=== Grok limitations
|
|
|
|
include::esql-process-data-with-dissect-grok.asciidoc[tag=grok-limitations]
|
|
|
|
[discrete]
|
|
[[esql-limitations-mv]]
|
|
=== Multivalue limitations
|
|
|
|
{esql} <<esql-multivalued-fields,supports multivalued fields>>, but functions
|
|
return `null` when applied to a multivalued field, unless documented otherwise.
|
|
Work around this limitation by converting the field to single value with one of
|
|
the <<esql-mv-functions,multivalue functions>>.
|
|
|
|
[discrete]
|
|
[[esql-limitations-timezone]]
|
|
=== Timezone support
|
|
|
|
{esql} only supports the UTC timezone.
|
|
|
|
[discrete]
|
|
[[esql-limitations-kibana]]
|
|
=== Kibana limitations
|
|
|
|
include::esql-kibana.asciidoc[tag=limitations]
|