using.asciidoc 5.3 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210
  1. [[modules-scripting-using]]
  2. === How to use scripts
  3. Wherever scripting is supported in the Elasticsearch API, the syntax follows
  4. the same pattern:
  5. [source,js]
  6. -------------------------------------
  7. "script": {
  8. "lang": "...", <1>
  9. "source" | "id": "...", <2>
  10. "params": { ... } <3>
  11. }
  12. -------------------------------------
  13. // NOTCONSOLE
  14. <1> The language the script is written in, which defaults to `painless`.
  15. <2> The script itself which may be specified as `source` for an inline script or `id` for a stored script.
  16. <3> Any named parameters that should be passed into the script.
  17. For example, the following script is used in a search request to return a
  18. <<search-request-script-fields, scripted field>>:
  19. [source,js]
  20. -------------------------------------
  21. PUT my_index/_doc/1
  22. {
  23. "my_field": 5
  24. }
  25. GET my_index/_search
  26. {
  27. "script_fields": {
  28. "my_doubled_field": {
  29. "script": {
  30. "lang": "expression",
  31. "source": "doc['my_field'] * multiplier",
  32. "params": {
  33. "multiplier": 2
  34. }
  35. }
  36. }
  37. }
  38. }
  39. -------------------------------------
  40. // CONSOLE
  41. [float]
  42. === Script Parameters
  43. `lang`::
  44. Specifies the language the script is written in. Defaults to `painless`.
  45. `source`, `id`::
  46. Specifies the source of the script. An `inline` script is specified
  47. `source` as in the example above. A `stored` script is specified `id`
  48. and is retrieved from the cluster state (see <<modules-scripting-stored-scripts,Stored Scripts>>).
  49. `params`::
  50. Specifies any named parameters that are passed into the script as
  51. variables.
  52. [IMPORTANT]
  53. [[prefer-params]]
  54. .Prefer parameters
  55. ========================================
  56. The first time Elasticsearch sees a new script, it compiles it and stores the
  57. compiled version in a cache. Compilation can be a heavy process.
  58. If you need to pass variables into the script, you should pass them in as
  59. named `params` instead of hard-coding values into the script itself. For
  60. example, if you want to be able to multiply a field value by different
  61. multipliers, don't hard-code the multiplier into the script:
  62. [source,js]
  63. ----------------------
  64. "source": "doc['my_field'] * 2"
  65. ----------------------
  66. // NOTCONSOLE
  67. Instead, pass it in as a named parameter:
  68. [source,js]
  69. ----------------------
  70. "source": "doc['my_field'] * multiplier",
  71. "params": {
  72. "multiplier": 2
  73. }
  74. ----------------------
  75. // NOTCONSOLE
  76. The first version has to be recompiled every time the multiplier changes. The
  77. second version is only compiled once.
  78. If you compile too many unique scripts within a small amount of time,
  79. Elasticsearch will reject the new dynamic scripts with a
  80. `circuit_breaking_exception` error. By default, up to 15 inline scripts per
  81. minute will be compiled. You can change this setting dynamically by setting
  82. `script.max_compilations_rate`.
  83. ========================================
  84. [float]
  85. [[modules-scripting-short-script-form]]
  86. === Short Script Form
  87. A short script form can be used for brevity. In the short form, `script` is represented
  88. by a string instead of an object. This string contains the source of the script.
  89. Short form:
  90. [source,js]
  91. ----------------------
  92. "script": "ctx._source.likes++"
  93. ----------------------
  94. // NOTCONSOLE
  95. The same script in the normal form:
  96. [source,js]
  97. ----------------------
  98. "script": {
  99. "source": "ctx._source.likes++"
  100. }
  101. ----------------------
  102. // NOTCONSOLE
  103. [float]
  104. [[modules-scripting-stored-scripts]]
  105. === Stored Scripts
  106. Scripts may be stored in and retrieved from the cluster state using the
  107. `_scripts` end-point.
  108. ==== Request Examples
  109. The following are examples of using a stored script that lives at
  110. `/_scripts/{id}`.
  111. First, create the script called `calculate-score` in the cluster state:
  112. [source,js]
  113. -----------------------------------
  114. POST _scripts/calculate-score
  115. {
  116. "script": {
  117. "lang": "painless",
  118. "source": "Math.log(_score * 2) + params.my_modifier"
  119. }
  120. }
  121. -----------------------------------
  122. // CONSOLE
  123. This same script can be retrieved with:
  124. [source,js]
  125. -----------------------------------
  126. GET _scripts/calculate-score
  127. -----------------------------------
  128. // CONSOLE
  129. // TEST[continued]
  130. Stored scripts can be used by specifying the `id` parameters as follows:
  131. [source,js]
  132. --------------------------------------------------
  133. GET _search
  134. {
  135. "query": {
  136. "script": {
  137. "script": {
  138. "id": "calculate-score",
  139. "params": {
  140. "my_modifier": 2
  141. }
  142. }
  143. }
  144. }
  145. }
  146. --------------------------------------------------
  147. // CONSOLE
  148. // TEST[continued]
  149. And deleted with:
  150. [source,js]
  151. -----------------------------------
  152. DELETE _scripts/calculate-score
  153. -----------------------------------
  154. // CONSOLE
  155. // TEST[continued]
  156. [float]
  157. [[modules-scripting-using-caching]]
  158. === Script Caching
  159. All scripts are cached by default so that they only need to be recompiled
  160. when updates occur. By default, scripts do not have a time-based expiration, but
  161. you can change this behavior by using the `script.cache.expire` setting.
  162. You can configure the size of this cache by using the `script.cache.max_size` setting.
  163. By default, the cache size is `100`.
  164. NOTE: The size of scripts is limited to 65,535 bytes. This can be
  165. changed by setting `script.max_size_in_bytes` setting to increase that soft
  166. limit, but if scripts are really large then a
  167. <<modules-scripting-engine,native script engine>> should be considered.