| 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211 | [[modules-scripting-using]]== How to use scriptsWherever scripting is supported in the Elasticsearch API, the syntax followsthe 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/_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        }      }    }  }}-------------------------------------// CONSOLE[float]=== Script parameters`lang`::    Specifies the language the script is written in.  Defaults to `painless`.`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 thecompiled version in a cache. Compilation can be a heavy process.If you need to pass variables into the script, you should pass them in asnamed `params` instead of hard-coding values into the script itself.  Forexample, if you want to be able to multiply a field value by differentmultipliers, don't hard-code the multiplier into the script:[source,js]----------------------  "source": "doc['my_field'] * 2"----------------------// NOTCONSOLEInstead, pass it in as a named parameter:[source,js]----------------------  "source": "doc['my_field'] * multiplier",  "params": {    "multiplier": 2  }----------------------// NOTCONSOLEThe first version has to be recompiled every time the multiplier changes.  Thesecond 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 perminute will be compiled. You can change this setting dynamically by setting`script.max_compilations_rate`.========================================[float][[modules-scripting-short-script-form]]=== Short script formA short script form can be used for brevity. In the short form, `script` is representedby a string instead of an object. This string contains the source of the script.Short form:[source,js]----------------------  "script": "ctx._source.likes++"----------------------// NOTCONSOLEThe same script in the normal form:[source,js]----------------------  "script": {    "source": "ctx._source.likes++"  }----------------------// NOTCONSOLE[float][[modules-scripting-stored-scripts]]=== Stored scriptsScripts may be stored in and retrieved from the cluster state using the`_scripts` end-point.[float]==== Request examplesThe 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"  }}-----------------------------------// CONSOLEThis 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 cachingAll scripts are cached by default so that they only need to be recompiledwhen updates occur. By default, scripts do not have a time-based expiration, butyou 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 scripts is limited to 65,535 bytes. This can bechanged by setting `script.max_size_in_bytes` setting to increase that softlimit, but if scripts are really large then a<<modules-scripting-engine,native script engine>> should be considered.
 |