Allow reusing the same scripts in sorts, aggregations and script queries

[jpountz]

Scripted queries and aggs provide a lot a flexibility. One downside however is that they require different kinds of scripts. It makes it challenging for Kibana to expose scripted fields.

Instead of expecting scripts of script queries to return a boolean, could we accept arbitrary search scripts and allow users to pass an expected value as well? This way the same scripts could be used in both queries and aggregations.

[elasticmachine]

Pinging @elastic/es-search (:Search/Search)

[mayya-sharipova]

Instead of expecting scripts of script queries to return a boolean, could we accept arbitrary search scripts and allow users to pass an expected value as well?

@jpountz This is not very clear to me. For example if we have a script "source": "doc['num1'].value * 10, is the idea that script query can run all different types of queries on these field values?

Do you have ideas how a potential API of this script query can look like?

[jpountz]

@mayya-sharipova I think there are many options, we'd need to weigh pros and cons, e.g.

• give existing queries (term, range, ...) a script parameter like we have on most aggregations so that they support scripts too
• add more options to the existing script query to tell how to check whether the produced value matches
• add ways to define fields as scripts as part of a search request, and allow these one-off scripted fields to be used in any query or aggregation

There might be other options I haven't thought of.

[mayya-sharipova]

add ways to define fields as scripts as part of a search request, and allow these one-off scripted fields to be used in any query or aggregation

I wonder if we can reuse already existing script_fields parameter in the query phase as well.

{
  "query": {
    "range": {
      "price_in_usd": {
        "lte": 100
      }
    }
  },
  "script_fields": {
    "price_in_usd": {
      "script": {
        "source": "doc['price'].value * 1.25"
      }
    }
  }
}

[jpountz]

I like the idea.

[javanna]

We are going to introduce support for runtime fields. The first implementation of them is going to be scripted runtime fields, which will address exactly the limitations mentioned in this issue, hence I am closing this in favour of #59332 .