`queries` block

[traut]

Background

Currently, the query attribute for content blocks allows users to query / transform the data from the context and store it under .query_result for convenience. Using query is not required but simplifies data requests in Go templates.

This approach has 2 limitations:

• query can be defined only in the content block, which limits its scope. The query must be copied-pasted if the same data transformation is required in multiple content blocks.
• users can specify only one query and the result of the query is stored under .query_result, making it impossible to have "variables" that simplify data access

Design

queries block

Introduce queries block that accepts string-to-string mappings of variable names and queries:

content text {
  queries {
    foo = ".data.inline.hosts[0]",
    bar = ".data.elasticsearch.alerts.hits.hits[0]._id"
  }

  value = "The first host is {{ .vars.foo.name }} and the first alert id is {{ .vars.bar }}"
}

The variable names used as keys in queries block are used in the context, under .vars root key, to store the corresponding query results.

queries block can be specified in document, section and content blocks. The queries are executed after the data blocks and for_each_query (so after dynamic unpacking - https://github.com/blackstork-io/fabric/issues/142).

If queries block is specified in a grouping block, like document or section, all nested children have .vars.<var> values in their contexts.

For example,

section {
  queries {
    foo = ".data.inline.hosts[0]",
    bar = ".data.elasticsearch.alerts.hits.hits[0]._id"
  }
  content text {
    value = "The first host is {{ .vars.foo.name }}"
  }
  content text {
    value = "The first alert id is {{ .vars.bar }}"
  }
}

query attribute

With the new queries block, an old query attribute becomes a syntax sugar that can be unpacked into:

queries {
    query_result = "<query-attribute-value>"
}

[!WARNING] This introduces a breaking change -- the value of the query will be accessible under .vars.query_result and not .query_result

Scope

To match the flexibility of the queries block, the query attribute should be allowed in document/ section / content blocks and behave exactly like the queries block with a single query_result value.

It is not allowed to use the 'queryattribute andqueries` block simultaneously.