fields.asciidoc 7.0 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261
  1. [[modules-scripting-fields]]
  2. == Accessing document fields and special variables
  3. Depending on where a script is used, it will have access to certain special
  4. variables and document fields.
  5. [float]
  6. == Update scripts
  7. A script used in the <<docs-update,update>>,
  8. <<docs-update-by-query,update-by-query>>, or <<docs-reindex,reindex>>
  9. API will have access to the `ctx` variable which exposes:
  10. [horizontal]
  11. `ctx._source`:: Access to the document <<mapping-source-field,`_source` field>>.
  12. `ctx.op`:: The operation that should be applied to the document: `index` or `delete`.
  13. `ctx._index` etc:: Access to <<mapping-fields,document meta-fields>>, some of which may be read-only.
  14. [float]
  15. == Search and aggregation scripts
  16. With the exception of <<request-body-search-script-fields,script fields>> which are
  17. executed once per search hit, scripts used in search and aggregations will be
  18. executed once for every document which might match a query or an aggregation.
  19. Depending on how many documents you have, this could mean millions or billions
  20. of executions: these scripts need to be fast!
  21. Field values can be accessed from a script using
  22. <<modules-scripting-doc-vals,doc-values>>,
  23. <<modules-scripting-source, the `_source` field>>, or
  24. <<modules-scripting-stored, stored fields>>,
  25. each of which is explained below.
  26. [[scripting-score]]
  27. [float]
  28. === Accessing the score of a document within a script
  29. Scripts used in the <<query-dsl-function-score-query,`function_score` query>>,
  30. in <<request-body-search-sort,script-based sorting>>, or in
  31. <<search-aggregations,aggregations>> have access to the `_score` variable which
  32. represents the current relevance score of a document.
  33. Here's an example of using a script in a
  34. <<query-dsl-function-score-query,`function_score` query>> to alter the
  35. relevance `_score` of each document:
  36. [source,console]
  37. -------------------------------------
  38. PUT my_index/_doc/1?refresh
  39. {
  40. "text": "quick brown fox",
  41. "popularity": 1
  42. }
  43. PUT my_index/_doc/2?refresh
  44. {
  45. "text": "quick fox",
  46. "popularity": 5
  47. }
  48. GET my_index/_search
  49. {
  50. "query": {
  51. "function_score": {
  52. "query": {
  53. "match": {
  54. "text": "quick brown fox"
  55. }
  56. },
  57. "script_score": {
  58. "script": {
  59. "lang": "expression",
  60. "source": "_score * doc['popularity']"
  61. }
  62. }
  63. }
  64. }
  65. }
  66. -------------------------------------
  67. [float]
  68. [[modules-scripting-doc-vals]]
  69. === Doc values
  70. By far the fastest most efficient way to access a field value from a
  71. script is to use the `doc['field_name']` syntax, which retrieves the field
  72. value from <<doc-values,doc values>>. Doc values are a columnar field value
  73. store, enabled by default on all fields except for <<text,analyzed `text` fields>>.
  74. [source,console]
  75. -------------------------------
  76. PUT my_index/_doc/1?refresh
  77. {
  78. "cost_price": 100
  79. }
  80. GET my_index/_search
  81. {
  82. "script_fields": {
  83. "sales_price": {
  84. "script": {
  85. "lang": "expression",
  86. "source": "doc['cost_price'] * markup",
  87. "params": {
  88. "markup": 0.2
  89. }
  90. }
  91. }
  92. }
  93. }
  94. -------------------------------
  95. Doc-values can only return "simple" field values like numbers, dates, geo-
  96. points, terms, etc, or arrays of these values if the field is multi-valued.
  97. It cannot return JSON objects.
  98. [NOTE]
  99. .Missing fields
  100. ===================================================
  101. The `doc['field']` will throw an error if `field` is missing from the mappings.
  102. In `painless`, a check can first be done with `doc.containsKey('field')` to guard
  103. accessing the `doc` map. Unfortunately, there is no way to check for the
  104. existence of the field in mappings in an `expression` script.
  105. ===================================================
  106. [NOTE]
  107. .Doc values and `text` fields
  108. ===================================================
  109. The `doc['field']` syntax can also be used for <<text,analyzed `text` fields>>
  110. if <<fielddata,`fielddata`>> is enabled, but *BEWARE*: enabling fielddata on a
  111. `text` field requires loading all of the terms into the JVM heap, which can be
  112. very expensive both in terms of memory and CPU. It seldom makes sense to
  113. access `text` fields from scripts.
  114. ===================================================
  115. [float]
  116. [[modules-scripting-source]]
  117. === The document `_source`
  118. The document <<mapping-source-field,`_source`>> can be accessed using the
  119. `_source.field_name` syntax. The `_source` is loaded as a map-of-maps, so
  120. properties within object fields can be accessed as, for example,
  121. `_source.name.first`.
  122. [IMPORTANT]
  123. .Prefer doc-values to _source
  124. =========================================================
  125. Accessing the `_source` field is much slower than using doc-values. The
  126. _source field is optimised for returning several fields per result, while doc
  127. values are optimised for accessing the value of a specific field in many
  128. documents.
  129. It makes sense to use `_source` when generating a
  130. <<request-body-search-script-fields,script field>> for the top ten hits from a
  131. search result but, for other search and aggregation use cases, always prefer
  132. using doc values.
  133. =========================================================
  134. For instance:
  135. [source,console]
  136. -------------------------------
  137. PUT my_index
  138. {
  139. "mappings": {
  140. "properties": {
  141. "first_name": {
  142. "type": "text"
  143. },
  144. "last_name": {
  145. "type": "text"
  146. }
  147. }
  148. }
  149. }
  150. PUT my_index/_doc/1?refresh
  151. {
  152. "first_name": "Barry",
  153. "last_name": "White"
  154. }
  155. GET my_index/_search
  156. {
  157. "script_fields": {
  158. "full_name": {
  159. "script": {
  160. "lang": "painless",
  161. "source": "params._source.first_name + ' ' + params._source.last_name"
  162. }
  163. }
  164. }
  165. }
  166. -------------------------------
  167. [float]
  168. [[modules-scripting-stored]]
  169. === Stored fields
  170. _Stored fields_ -- fields explicitly marked as
  171. <<mapping-store,`"store": true`>> in the mapping -- can be accessed using the
  172. `_fields['field_name'].value` or `_fields['field_name']` syntax:
  173. [source,console]
  174. -------------------------------
  175. PUT my_index
  176. {
  177. "mappings": {
  178. "properties": {
  179. "full_name": {
  180. "type": "text",
  181. "store": true
  182. },
  183. "title": {
  184. "type": "text",
  185. "store": true
  186. }
  187. }
  188. }
  189. }
  190. PUT my_index/_doc/1?refresh
  191. {
  192. "full_name": "Alice Ball",
  193. "title": "Professor"
  194. }
  195. GET my_index/_search
  196. {
  197. "script_fields": {
  198. "name_with_title": {
  199. "script": {
  200. "lang": "painless",
  201. "source": "params._fields['title'].value + ' ' + params._fields['full_name'].value"
  202. }
  203. }
  204. }
  205. }
  206. -------------------------------
  207. [TIP]
  208. .Stored vs `_source`
  209. =======================================================
  210. The `_source` field is just a special stored field, so the performance is
  211. similar to that of other stored fields. The `_source` provides access to the
  212. original document body that was indexed (including the ability to distinguish
  213. `null` values from empty fields, single-value arrays from plain scalars, etc).
  214. The only time it really makes sense to use stored fields instead of the
  215. `_source` field is when the `_source` is very large and it is less costly to
  216. access a few small stored fields instead of the entire `_source`.
  217. =======================================================