mirror of
https://github.com/honeymoose/OpenSearch.git
synced 2025-02-06 04:58:50 +00:00
35a58d874e
This change unifies the way scripts and templates are specified for all instances in the codebase. It builds on the Script class added previously and adds request building and parsing support as well as the ability to transfer script objects between nodes. It also adds a Template class which aims to provide the same functionality for template APIs Closes #11091
63 lines
1.9 KiB
Plaintext
63 lines
1.9 KiB
Plaintext
[[search-request-script-fields]]
|
|
=== Script Fields
|
|
|
|
Allows to return a <<modules-scripting,script
|
|
evaluation>> (based on different fields) for each hit, for example:
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
{
|
|
"query" : {
|
|
...
|
|
},
|
|
"script_fields" : {
|
|
"test1" : {
|
|
"script" : "doc['my_field_name'].value * 2"
|
|
},
|
|
"test2" : {
|
|
"script" : {
|
|
"inline": "doc['my_field_name'].value * factor",
|
|
"params" : {
|
|
"factor" : 2.0
|
|
}
|
|
}
|
|
}
|
|
}
|
|
}
|
|
--------------------------------------------------
|
|
|
|
Script fields can work on fields that are not stored (`my_field_name` in
|
|
the above case), and allow to return custom values to be returned (the
|
|
evaluated value of the script).
|
|
|
|
Script fields can also access the actual `_source` document indexed and
|
|
extract specific elements to be returned from it (can be an "object"
|
|
type). Here is an example:
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
{
|
|
"query" : {
|
|
...
|
|
},
|
|
"script_fields" : {
|
|
"test1" : {
|
|
"script" : "_source.obj1.obj2"
|
|
}
|
|
}
|
|
}
|
|
--------------------------------------------------
|
|
|
|
Note the `_source` keyword here to navigate the json-like model.
|
|
|
|
It's important to understand the difference between
|
|
`doc['my_field'].value` and `_source.my_field`. The first, using the doc
|
|
keyword, will cause the terms for that field to be loaded to memory
|
|
(cached), which will result in faster execution, but more memory
|
|
consumption. Also, the `doc[...]` notation only allows for simple valued
|
|
fields (can't return a json object from it) and make sense only on
|
|
non-analyzed or single term based fields.
|
|
|
|
The `_source` on the other hand causes the source to be loaded, parsed,
|
|
and then only the relevant part of the json is returned.
|