You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We would like to increase the flexibility of the search API by introducing support for runtime fields.
Runtime fields are not indexed and do not have doc_values, meaning Lucene is completely unaware of them, but they are consumed through the field capabilities API and the search API like any ordinary field. It is possible to retrieve them as well as query them, aggregate and sort on them.
Runtime fields make searches slower, as computing their values for each document (that may match the query) is costly, depending on how they are calculated; it is highly recommended that the Async Search API is used to run searches that use runtime fields.
One limitation of runtime fields compared to ordinary fields is that they don’t support scoring as they are not indexed and we are not going to compute the document frequency for them, which is required for scoring.
Runtime fields are not part of the _source, hence they are not returned by default as part of the search hits. They can be specifically requested through the field retrieval API (#55363).
A runtime field is defined by its data type and the script that computes its values. As of today, each search section already supports scripting, but the contexts are different, as well as the required syntax. We want to unify this to a single place where a script can be specified. Such a script always has access to _source, any other stored fields as well as doc_values.
A runtime fields can be defined in the mappings by adding its definition to a new runtime section at the same level as properties, where fields that exist in _source are defined:
The data types supported for runtime fields are initially keyword, long, double, date, ip, boolean, geo_point. In the example above, we extract the day of week (e.g. Monday) from another field called timestamp which is defined as a date. The script can refer to other fields, including other runtime fields: we need to implement a mechanism to resolve fields dependencies in the correct order, and prevent cyclic dependencies.
The defined field can then be used like any other field in the different sections of the search API:
Each runtime field type will consist of a MappedFieldType that exposes a runtime fielddata implementation that generates doc_values on the fly for the needed data type. Additionally, all the basic Lucene queries for each runtime field type need to be written to query the corresponding fielddata/doc_values implementation.
Support for runtime fields in Elasticsearch will be released under the Elastic license.
The following is a high-level list of tasks required to develop the initial support for runtime fields, which will lay the foundations for the next phases:
Runtime fields
We would like to increase the flexibility of the search API by introducing support for runtime fields.
Runtime fields are not indexed and do not have doc_values, meaning Lucene is completely unaware of them, but they are consumed through the field capabilities API and the search API like any ordinary field. It is possible to retrieve them as well as query them, aggregate and sort on them.
Runtime fields make searches slower, as computing their values for each document (that may match the query) is costly, depending on how they are calculated; it is highly recommended that the Async Search API is used to run searches that use runtime fields.
One limitation of runtime fields compared to ordinary fields is that they don’t support scoring as they are not indexed and we are not going to compute the document frequency for them, which is required for scoring.
Runtime fields are not part of the _source, hence they are not returned by default as part of the search hits. They can be specifically requested through the field retrieval API (#55363).
A runtime field is defined by its data type and the script that computes its values. As of today, each search section already supports scripting, but the contexts are different, as well as the required syntax. We want to unify this to a single place where a script can be specified. Such a script always has access to
_source, any other stored fields as well as doc_values.A runtime fields can be defined in the mappings by adding its definition to a new
runtimesection at the same level asproperties, where fields that exist in _source are defined:The data types supported for runtime fields are initially
keyword,long,double,date,ip,boolean,geo_point. In the example above, we extract the day of week (e.g. Monday) from another field calledtimestampwhich is defined as adate. The script can refer to other fields, including other runtime fields: we need to implement a mechanism to resolve fields dependencies in the correct order, and prevent cyclic dependencies.The defined field can then be used like any other field in the different sections of the search API:
Each runtime field type will consist of a
MappedFieldTypethat exposes a runtime fielddata implementation that generates doc_values on the fly for the needed data type. Additionally, all the basic Lucene queries for each runtime field type need to be written to query the corresponding fielddata/doc_values implementation.Support for runtime fields in Elasticsearch will be released under the Elastic license.
The following is a high-level list of tasks required to develop the initial support for runtime fields, which will lay the foundations for the next phases:
Mappers and field types
ScriptServiceavailable when parsing field mappers (Add the ScriptService to the field parser config #60933)runtimefield mapper with dynamic mapped field type, one per supported runtime_type (Scripted keyword field #58939, Make ScriptFieldMapper a parameterized mapper #59391, Runtime fields: rework script service injection #59659, Render script params in script field xcontent #59813, Standardize script field's rejection error #60029, Replace script unit tests with integration tests #60027, Runtime script field mapper to reject copy_to and fields #60580)keywordfield type (Add term query for keyword script fields #59372, Two queries for keyword script field #59527, Add tests for keyword script field's fielddata #59523, Remaining queries for script keyword fields #59630, Scripted keyword field type: update family type and test field caps output #59672, Error on bad shape relations in runtime fields #60463)long(Add long flavored script field #59721, Remaining queries for long script field #59816, ScriptLongFieldData to extend LeafLongFieldData #59884)double(Add double script fields #59933)datefield type (Add runtime_script date field #60092, Format support for script doc fields #60465, Add a consistent way to parse dates #61105)ipfield type (Implement runtime script ips #60533 + Fixvaluemethod on ip scripts #61230)booleanfield type (Add boolean values script fields #60830)API
Scripting
Infrastructure
SearchLookupavailable toMappedFieldType#fielddataBuilder(Pass a SearchLookup supplier through to fielddataBuilder #60224. Pass SearchLookup supplier through to fielddataBuilder #61430)Security
Telemetry
Docs
runtimesection and corresponding field types ([DOCS] Add docs for runtime fields #62653)