[[modules-scripting-using]] == How to write scripts Wherever scripting is supported in the {es} APIs, the syntax follows the same pattern; you specify the language of your script, provide the script logic (or source, and add parameters that are passed into the script: [source,js] ------------------------------------- "script": { "lang": "...", "source" | "id": "...", "params": { ... } } ------------------------------------- // NOTCONSOLE `lang`:: Specifies the language the script is written in. Defaults to `painless`. `source`, `id`:: The script itself, which you specify as `source` for an inline script or `id` for a stored script. Use the `_scripts` endpoint to retrieve a stored script. For example, you can create or delete a <> by calling `POST _scripts/{id}` and `DELETE _scripts/{id}`. `params`:: Specifies any named parameters that are passed into the script as variables. <> instead of hard-coded values to decrease compile time. [discrete] [[hello-world-script]] === Write your first script <> is the default scripting language for {es}. It is secure, performant, and provides a natural syntax for anyone with a little coding experience. A Painless script is structured as one or more statements and optionally has one or more user-defined functions at the beginning. A script must always have at least one statement. The {painless}/painless-execute-api.html[Painless execute API] provides the ability to test a script with simple user-defined parameters and receive a result. Let's start with a complete script and review its constituent parts. First, index a document with a single field so that we have some data to work with: [source,console] ---- PUT my-index-000001/_doc/1 { "my_field": 5 } ---- We can then construct a script that operates on that field and run evaluate the script as part of a query. The following query uses the <> parameter of the search API to retrieve a script valuation. There's a lot happening here, but we'll break it down the components to understand them individually. For now, you only need to understand that this script takes `my_field` and operates on it. [source,console] ---- GET my-index-000001/_search { "script_fields": { "my_doubled_field": { "script": { <1> "source": "doc['my_field'].value * params['multiplier']", <2> "params": { "multiplier": 2 } } } } } ---- // TEST[continued] <1> `script` object <2> `script` source The `script` is a standard JSON object that defines scripts under most APIs in {es}. This object requires `source` to define the script itself. The script doesn't specify a language, so it defaults to Painless. [discrete] [[prefer-params]] === Use parameters in your script The first time {es} sees a new script, it compiles the script and stores the compiled version in a cache. Compilation can be a heavy process. Rather than hard-coding values in your script, pass them as named `params` instead. For example, in the previous script, we could have just hard coded values and written a script that is seemingly less complex. We could just retrieve the first value for `my_field` and then multiply it by `2`: [source,painless] ---- "source": "return doc['my_field'].value * 2" ---- Though it works, this solution is pretty inflexible. We have to modify the script source to change the multiplier, and {es} has to recompile the script every time that the multiplier changes. Instead of hard-coding values, use named `params` to make scripts flexible, and also reduce compilation time when the script runs. You can now make changes to the `multiplier` parameter without {es} recompiling the script. [source,painless] ---- "source": "doc['my_field'].value * params['multiplier']", "params": { "multiplier": 2 } ---- For most contexts, you can compile up to 75 scripts per 5 minutes by default. For ingest contexts, the default script compilation rate is unlimited. You can change these settings dynamically by setting `script.context.$CONTEXT.max_compilations_rate`. For example, the following setting limits script compilation to 100 scripts every 10 minutes for the {painless}/painless-field-context.html[field context]: [source,js] ---- script.context.field.max_compilations_rate=100/10m ---- // NOTCONSOLE IMPORTANT: If you compile too many unique scripts within a short time, {es} rejects the new dynamic scripts with a `circuit_breaking_exception` error. [discrete] [[script-shorten-syntax]] === Shorten your script Using syntactic abilities that are native to Painless, you can reduce verbosity in your scripts and make them shorter. Here's a simple script that we can make shorter: [source,console] ---- GET my-index-000001/_search { "script_fields": { "my_doubled_field": { "script": { "lang": "painless", "source": "return doc['my_field'].value * params.get('multiplier');", "params": { "multiplier": 2 } } } } } ---- // TEST[s/^/PUT my-index-000001\n/] Let's look at a shortened version of the script to see what improvements it includes over the previous iteration: [source,console] ---- GET my-index-000001/_search { "script_fields": { "my_doubled_field": { "script": { "source": "doc['my_field'].value * params['multiplier']", "params": { "multiplier": 2 } } } } } ---- // TEST[s/^/PUT my-index-000001\n/] This version of the script removes several components and simplifies the syntax significantly: * The `lang` declaration. Because Painless is the default language, you don't need to specify the language if you're writing a Painless script. * The `return` keyword. Painless automatically uses the final statement in a script (when possible) to produce a return value in a script context that requires one. * The `get` method, which is replaced with brackets `[]`. Painless uses a shortcut specifically for the `Map` type that allows us to use brackets instead of the lengthier `get` method. * The semicolon at the end of the `source` statement. Painless does not require semicolons for the final statement of a block. However, it does require them in other cases to remove ambiguity. Use this abbreviated syntax anywhere that {es} supports scripts, such as when you're creating <>. [discrete] [[script-stored-scripts]] === Store and retrieve scripts You can store and retrieve scripts from the cluster state using the `_scripts` endpoint. Using stored scripts can help to reduce compilation time and make searches faster. Use the `{id}` path element in `_scripts/{id}` to refer to a stored script. NOTE: Unlike regular scripts, stored scripts require that you specify a script language using the `lang` parameter. For example, let's create a stored script in the cluster named `calculate-score`: [source,console] ----------------------------------- POST _scripts/calculate-score { "script": { "lang": "painless", "source": "Math.log(_score * 2) + params['my_modifier']" } } ----------------------------------- // TEST[setup:my_index] You can retrieve that script by using the `_scripts` endpoint: [source,console] ----------------------------------- GET _scripts/calculate-score ----------------------------------- // TEST[continued] To use the stored script in a query, include the script `id` in the `script` declaration: [source,console] ---- GET my-index-000001/_search { "query": { "script_score": { "query": { "match": { "message": "some message" } }, "script": { "id": "calculate-score", <1> "params": { "my_modifier": 2 } } } } } ---- // TEST[continued] <1> `id` of the stored script To delete a stored script, submit a delete request to the `_scripts` endpoint and specify the stored script `id`: [source,console] ---- DELETE _scripts/calculate-score ---- // TEST[continued] [discrete] [[scripts-update-scripts]] === Update documents with scripts You can use the <> to update documents with a specified script. The script can update, delete, or skip modifying the document. The update API also supports passing a partial document, which is merged into the existing document. First, let's index a simple document: [source,console] ---- PUT my-index-000001/_doc/1 { "counter" : 1, "tags" : ["red"] } ---- To increment the counter, you can submit an update request with the following script: [source,console] ---- POST my-index-000001/_update/1 { "script" : { "source": "ctx._source.counter += params.count", "lang": "painless", "params" : { "count" : 4 } } } ---- // TEST[continued] Similarly, you can use an update script to add a tag to the list of tags. Because this is just a list, the tag is added even it exists: [source,console] ---- POST my-index-000001/_update/1 { "script": { "source": "ctx._source.tags.add(params['tag'])", "lang": "painless", "params": { "tag": "blue" } } } ---- // TEST[continued] You can also remove a tag from the list of tags. The `remove` method of a Java `List` is available in Painless. It takes the index of the element you want to remove. To avoid a possible runtime error, you first need to make sure the tag exists. If the list contains duplicates of the tag, this script just removes one occurrence. [source,console] ---- POST my-index-000001/_update/1 { "script": { "source": "if (ctx._source.tags.contains(params['tag'])) { ctx._source.tags.remove(ctx._source.tags.indexOf(params['tag'])) }", "lang": "painless", "params": { "tag": "blue" } } } ---- // TEST[continued] You can also add and remove fields from a document. For example, this script adds the field `new_field`: [source,console] ---- POST my-index-000001/_update/1 { "script" : "ctx._source.new_field = 'value_of_new_field'" } ---- // TEST[continued] Conversely, this script removes the field `new_field`: [source,console] ---- POST my-index-000001/_update/1 { "script" : "ctx._source.remove('new_field')" } ---- // TEST[continued] Instead of updating the document, you can also change the operation that is executed from within the script. For example, this request deletes the document if the `tags` field contains `green`. Otherwise it does nothing (`noop`): [source,console] ---- POST my-index-000001/_update/1 { "script": { "source": "if (ctx._source.tags.contains(params['tag'])) { ctx.op = 'delete' } else { ctx.op = 'none' }", "lang": "painless", "params": { "tag": "green" } } } ---- // TEST[continued] [[scripts-and-search-speed]] === Scripts, caching, and search speed {es} performs a number of optimizations to make using scripts as fast as possible. One important optimization is a script cache. The compiled script is placed in a cache so that requests that reference the script do not incur a compilation penalty. Cache sizing is important. Your script cache should be large enough to hold all of the scripts that users need to be accessed concurrently. If you see a large number of script cache evictions and a rising number of compilations in <>, your cache might be too small. 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. You can change this behavior by using the `script.cache.expire` setting. Use the `script.cache.max_size` setting to configure the size of the cache. NOTE: The size of scripts is limited to 65,535 bytes. Set the value of `script.max_size_in_bytes` to increase that soft limit. If your scripts are really large, then consider using a <>. [discrete] ==== Improving search speed Scripts are incredibly useful, but can't use {es}'s index structures or related optimizations. This relationship can sometimes result in slower search speeds. If you often use scripts to transform indexed data, you can make search faster by transforming data during ingest instead. However, that often means slower index speeds. Let's look at a practical example to illustrate how you can increase search speed. When running searches, it's common to sort results by the sum of two values. For example, consider an index named `my_test_scores` that contains test score data. This index includes two fields of type `long`: * `math_score` * `verbal_score` You can run a query with a script that adds these values together. There's nothing wrong with this approach, but the query will be slower because the script valuation occurs as part of the request. The following request returns documents where `grad_year` equals `2099`, and sorts by the results by the valuation of the script. [source,console] ---- GET /my_test_scores/_search { "query": { "term": { "grad_year": "2099" } }, "sort": [ { "_script": { "type": "number", "script": { "source": "doc['math_score'].value + doc['verbal_score'].value" }, "order": "desc" } } ] } ---- // TEST[s/^/PUT my_test_scores\n/] If you're searching a small index, then including the script as part of your search query can be a good solution. If you want to make search faster, you can perform this calculation during ingest and index the sum to a field instead. First, we'll add a new field to the index named `total_score`, which will contain sum of the `math_score` and `verbal_score` field values. [source,console] ---- PUT /my_test_scores/_mapping { "properties": { "total_score": { "type": "long" } } } ---- // TEST[continued] Next, use an <> containing the <> to calculate the sum of `math_score` and `verbal_score` and index it in the `total_score` field. [source,console] ---- PUT _ingest/pipeline/my_test_scores_pipeline { "description": "Calculates the total test score", "processors": [ { "script": { "source": "ctx.total_score = (ctx.math_score + ctx.verbal_score)" } } ] } ---- // TEST[continued] To update existing data, use this pipeline to <> any documents from `my_test_scores` to a new index named `my_test_scores_2`. [source,console] ---- POST /_reindex { "source": { "index": "my_test_scores" }, "dest": { "index": "my_test_scores_2", "pipeline": "my_test_scores_pipeline" } } ---- // TEST[continued] Continue using the pipeline to index any new documents to `my_test_scores_2`. [source,console] ---- POST /my_test_scores_2/_doc/?pipeline=my_test_scores_pipeline { "student": "kimchy", "grad_year": "2099", "math_score": 1200, "verbal_score": 800 } ---- // TEST[continued] These changes slow the index process, but allow for faster searches. Instead of using a script, you can sort searches made on `my_test_scores_2` using the `total_score` field. The response is near real-time! Though this process slows ingest time, it greatly increases queries at search time. [source,console] ---- GET /my_test_scores_2/_search { "query": { "term": { "grad_year": "2099" } }, "sort": [ { "total_score": { "order": "desc" } } ] } ---- // TEST[continued] //// [source,console] ---- DELETE /_ingest/pipeline/my_test_scores_pipeline ---- // TEST[continued] //// include::common-script-uses.asciidoc[]