Wherever scripting is supported in the Elasticsearch API, the syntax follows the same pattern:
The language the script is written in, which defaults to | |
The script itself which may be specified as | |
Any named parameters that should be passed into the script. |
For example, the following script is used in a search request to return a scripted field:
PUT my_index/_doc/1
{
"my_field": 5
}
GET my_index/_search
{
"script_fields": {
"my_doubled_field": {
"script": {
"lang": "expression",
"source": "doc['my_field'] * multiplier",
"params": {
"multiplier": 2
}
}
}
}
}lang
painless.
source, id
inline script is specified
source as in the example above. A stored script is specified id
and is retrieved from the cluster state (see Stored Scripts).
params
The first time Elasticsearch sees a new script, it compiles it and stores the compiled version in a cache. Compilation can be a heavy process.
If you need to pass variables into the script, you should pass them in as
named params instead of hard-coding values into the script itself. For
example, if you want to be able to multiply a field value by different
multipliers, don’t hard-code the multiplier into the script:
"source": "doc['my_field'] * 2"
Instead, pass it in as a named parameter:
"source": "doc['my_field'] * multiplier",
"params": {
"multiplier": 2
}The first version has to be recompiled every time the multiplier changes. The second version is only compiled once.
If you compile too many unique scripts within a small amount of time,
Elasticsearch will reject the new dynamic scripts with a
circuit_breaking_exception error. By default, up to 15 inline scripts per
minute will be compiled. You can change this setting dynamically by setting
script.max_compilations_rate.
A short script form can be used for brevity. In the short form, script is represented
by a string instead of an object. This string contains the source of the script.
Short form:
"script": "ctx._source.likes++"
The same script in the normal form:
"script": {
"source": "ctx._source.likes++"
}Scripts may be stored in and retrieved from the cluster state using the
_scripts end-point.
The following are examples of using a stored script that lives at
/_scripts/{id}.
First, create the script called calculate-score in the cluster state:
POST _scripts/calculate-score
{
"script": {
"lang": "painless",
"source": "Math.log(_score * 2) + params.my_modifier"
}
}This same script can be retrieved with:
GET _scripts/calculate-score
Stored scripts can be used by specifying the id parameters as follows:
GET _search
{
"query": {
"script": {
"script": {
"id": "calculate-score",
"params": {
"my_modifier": 2
}
}
}
}
}And deleted with:
DELETE _scripts/calculate-score
All scripts are cached by default so that they only need to be recompiled
when updates occur. By default, scripts do not have a time-based expiration, but
you can change this behavior by using the script.cache.expire setting.
You can configure the size of this cache by using the script.cache.max_size setting.
By default, the cache size is 100.
The size of scripts is limited to 65,535 bytes. This can be
changed by setting script.max_size_in_bytes setting to increase that soft
limit, but if scripts are really large then a
native script engine should be considered.