mirror of
https://github.com/honeymoose/OpenSearch.git
synced 2025-03-09 14:34:43 +00:00
This commit adds back "id" as the key within a script to specify a stored script (which with file scripts now gone is no longer ambiguous). It also adds "source" as a replacement for "code". This is in an attempt to normalize how scripts are specified across both put stored scripts and script usages, including search template requests. This also deprecates the old inline/stored keys.
214 lines
6.1 KiB
Plaintext
214 lines
6.1 KiB
Plaintext
[[modules-scripting-using]]
|
|
=== How to use scripts
|
|
|
|
Wherever scripting is supported in the Elasticsearch API, the syntax follows
|
|
the same pattern:
|
|
|
|
[source,js]
|
|
-------------------------------------
|
|
"script": {
|
|
"lang": "...", <1>
|
|
"source" | "id": "...", <2>
|
|
"params": { ... } <3>
|
|
}
|
|
-------------------------------------
|
|
// NOTCONSOLE
|
|
<1> The language the script is written in, which defaults to `painless`.
|
|
<2> The script itself which may be specified as `source` for an inline script or `id` for a stored script.
|
|
<3> Any named parameters that should be passed into the script.
|
|
|
|
For example, the following script is used in a search request to return a
|
|
<<search-request-script-fields, scripted field>>:
|
|
|
|
[source,js]
|
|
-------------------------------------
|
|
PUT my_index/my_type/1
|
|
{
|
|
"my_field": 5
|
|
}
|
|
|
|
GET my_index/_search
|
|
{
|
|
"script_fields": {
|
|
"my_doubled_field": {
|
|
"script": {
|
|
"lang": "expression",
|
|
"source": "doc['my_field'] * multiplier",
|
|
"params": {
|
|
"multiplier": 2
|
|
}
|
|
}
|
|
}
|
|
}
|
|
}
|
|
-------------------------------------
|
|
// CONSOLE
|
|
|
|
[float]
|
|
=== Script Parameters
|
|
|
|
`lang`::
|
|
|
|
Specifies the language the script is written in. Defaults to `painless` but
|
|
may be set to any of languages listed in <<modules-scripting>>. The
|
|
default language may be changed in the `elasticsearch.yml` config file by
|
|
setting `script.default_lang` to the appropriate language.
|
|
|
|
|
|
`source`, `id`::
|
|
|
|
Specifies the source of the script. An `inline` script is specified
|
|
`source` as in the example above. A `stored` script is specified `id`
|
|
and is retrieved from the cluster state (see <<modules-scripting-stored-scripts,Stored Scripts>>).
|
|
|
|
|
|
`params`::
|
|
|
|
Specifies any named parameters that are passed into the script as
|
|
variables.
|
|
|
|
[IMPORTANT]
|
|
[[prefer-params]]
|
|
.Prefer parameters
|
|
========================================
|
|
|
|
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,js]
|
|
----------------------
|
|
"source": "doc['my_field'] * 2"
|
|
----------------------
|
|
// NOTCONSOLE
|
|
|
|
Instead, pass it in as a named parameter:
|
|
|
|
[source,js]
|
|
----------------------
|
|
"source": "doc['my_field'] * multiplier",
|
|
"params": {
|
|
"multiplier": 2
|
|
}
|
|
----------------------
|
|
// NOTCONSOLE
|
|
|
|
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_per_minute`.
|
|
|
|
========================================
|
|
|
|
[float]
|
|
[[modules-scripting-stored-scripts]]
|
|
=== Stored Scripts
|
|
|
|
Scripts may be stored in and retrieved from the cluster state using the
|
|
`_scripts` end-point.
|
|
|
|
==== Deprecated Namespace
|
|
|
|
The namespace for stored scripts using both `lang` and `id` as a unique
|
|
identifier has been deprecated. The new namespace for stored scripts will
|
|
only use `id`. Stored scripts with the same `id`, but different `lang`'s
|
|
will no longer be allowed in 6.0. To comply with the new namespace for
|
|
stored scripts, existing stored scripts should be deleted and put again.
|
|
Any scripts that share an `id` but have different `lang`s will need to
|
|
be re-named. For example, take the following:
|
|
|
|
"id": "example", "lang": "painless"
|
|
"id": "example", "lang": "expressions"
|
|
|
|
The above scripts will conflict under the new namespace since the id's are
|
|
the same. At least one will have to be re-named to comply with the new
|
|
namespace of only `id`.
|
|
|
|
As a final caveat, stored search templates and stored scripts share
|
|
the same namespace, so if a search template has the same `id` as a
|
|
stored script, one of the two will have to be re-named as well using
|
|
delete and put requests.
|
|
|
|
==== Request Examples
|
|
|
|
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:
|
|
|
|
[source,js]
|
|
-----------------------------------
|
|
POST _scripts/calculate-score
|
|
{
|
|
"script": {
|
|
"lang": "painless",
|
|
"source": "Math.log(_score * 2) + params.my_modifier"
|
|
}
|
|
}
|
|
-----------------------------------
|
|
// CONSOLE
|
|
|
|
This same script can be retrieved with:
|
|
|
|
[source,js]
|
|
-----------------------------------
|
|
GET _scripts/calculate-score
|
|
-----------------------------------
|
|
// CONSOLE
|
|
// TEST[continued]
|
|
|
|
Stored scripts can be used by specifying the `id` parameters as follows:
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
GET _search
|
|
{
|
|
"query": {
|
|
"script": {
|
|
"script": {
|
|
"id": "calculate-score",
|
|
"params": {
|
|
"my_modifier": 2
|
|
}
|
|
}
|
|
}
|
|
}
|
|
}
|
|
--------------------------------------------------
|
|
// CONSOLE
|
|
// TEST[continued]
|
|
|
|
And deleted with:
|
|
|
|
[source,js]
|
|
-----------------------------------
|
|
DELETE _scripts/calculate-score
|
|
-----------------------------------
|
|
// CONSOLE
|
|
// TEST[continued]
|
|
|
|
[float]
|
|
[[modules-scripting-using-caching]]
|
|
=== Script Caching
|
|
|
|
All scripts are cached by default so that they only need to be recompiled
|
|
when updates occur. File scripts keep a static cache and will always reside
|
|
in memory. Both inline and stored scripts are stored in a cache that can evict
|
|
residing scripts. 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`.
|
|
|
|
NOTE: The size of stored 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 alternatives like
|
|
<<modules-scripting-native,native>> scripts should be considered instead.
|