[Query] Compound

This document was generated from 'src/documentation/wiki-query.ts' on 2026-07-20, 13:05:04 UTC presenting an overview of flowR's query API (v2.12.3). Please do not edit this file/wiki page directly.

Compound Query ^[overview]

Combines multiple queries of the same type into one, specifying common arguments.
This query is requested with the type compound.

A compound query comes in use, whenever we want to state multiple queries of the same type with a set of common arguments. It offers the following properties of interest:

1. Query (query): the type of the query that is to be combined.
2. Common Arguments (commonArguments): The arguments that are to be used as defaults for all queries (i.e., any argument the query may have).
3. Arguments (arguments): The other arguments for the individual queries that are to be combined.

For example, consider the following compound query that combines two call-context queries for mean and print, both of which are to be assigned to the kind visualize and the subkind text (using the example code from above):

[
  {
    "type": "compound",
    "query": "call-context",
    "commonArguments": {
      "kind": "visualize",
      "subkind": "text"
    },
    "arguments": [
      {
        "callName": "^mean$"
      },
      {
        "callName": "^print$"
      }
    ]
  }
]

Results (prettified and summarized):

Query: call-context (0 ms)
   ╰ visualize (4 hits):
     ╰ text (4 hits): mean(data$x) (L.9), print(m) (L.10), mean(data2$k) (L.19), print(mean(data2$k)) (L.19)
All queries together required ≈11 ms (1ms accuracy, total 11 ms)

Show Detailed Results as Json

The analysis required 11.4 ms (including parsing and normalization and the query) within the generation environment.

In general, the JSON contains the Ids of the nodes in question as they are present in the normalized AST or the dataflow graph of flowR. Please consult the Interface wiki page for more information on how to get those.

{
  "call-context": {
    ".meta": {
      "timing": 0
    },
    "kinds": {
      "visualize": {
        "subkinds": {
          "text": [
            {
              "id": 31,
              "name": "mean"
            },
            {
              "id": 36,
              "name": "print"
            },
            {
              "id": 87,
              "name": "mean"
            },
            {
              "id": 89,
              "name": "print"
            }
          ]
        }
      }
    }
  },
  ".meta": {
    "timing": 11
  }
}

Of course, in this specific scenario, the following query would be equivalent:

[
  {
    "type": "call-context",
    "callName": "^(mean|print)$",
    "kind": "visualize",
    "subkind": "text"
  }
]

Show Results

Results (prettified and summarized):

Query: call-context (1 ms)
   ╰ visualize (4 hits):
     ╰ text (4 hits): mean(data$x) (L.9), print(m) (L.10), mean(data2$k) (L.19), print(mean(data2$k)) (L.19)
All queries together required ≈10 ms (1ms accuracy, total 10 ms)

Show Detailed Results as Json

The analysis required 10.3 ms (including parsing and normalization and the query) within the generation environment.

In general, the JSON contains the Ids of the nodes in question as they are present in the normalized AST or the dataflow graph of flowR. Please consult the Interface wiki page for more information on how to get those.

{
  "call-context": {
    ".meta": {
      "timing": 1
    },
    "kinds": {
      "visualize": {
        "subkinds": {
          "text": [
            {
              "id": 31,
              "name": "mean"
            },
            {
              "id": 36,
              "name": "print"
            },
            {
              "id": 87,
              "name": "mean"
            },
            {
              "id": 89,
              "name": "print"
            }
          ]
        }
      }
    }
  },
  ".meta": {
    "timing": 10
  }
}

However, compound queries become more useful whenever common arguments can not be expressed as a union in one of their properties. Additionally, you can still overwrite default arguments. In the following, we (by default) want all calls to not resolve to a local definition, except for those to print for which we explicitly want to resolve to a local definition:

[
  {
    "type": "compound",
    "query": "call-context",
    "commonArguments": {
      "kind": "visualize",
      "subkind": "text",
      "callTargets": "global"
    },
    "arguments": [
      {
        "callName": "^mean$"
      },
      {
        "callName": "^print$",
        "callTargets": "local"
      }
    ]
  }
]

Results (prettified and summarized):

Query: call-context (0 ms)
   ╰ visualize (2 hits):
     ╰ text (2 hits): mean(data$x) (L.9) with 1 call (UNKNOWN: built-in (info: undefined)), mean(data2$k) (L.19) with 1 call (UNKNOWN: built-in (info: undefined))
All queries together required ≈13 ms (1ms accuracy, total 13 ms)

Show Detailed Results as Json

The analysis required 13.4 ms (including parsing and normalization and the query) within the generation environment.

In general, the JSON contains the Ids of the nodes in question as they are present in the normalized AST or the dataflow graph of flowR. Please consult the Interface wiki page for more information on how to get those.

{
  "call-context": {
    ".meta": {
      "timing": 0
    },
    "kinds": {
      "visualize": {
        "subkinds": {
          "text": [
            {
              "id": 31,
              "name": "mean",
              "calls": [
                "built-in"
              ]
            },
            {
              "id": 87,
              "name": "mean",
              "calls": [
                "built-in"
              ]
            }
          ]
        }
      }
    }
  },
  ".meta": {
    "timing": 13
  }
}

Now, the results no longer contain calls to plot that are not defined locally.

Implementation Details

Responsible for the execution of the Compound Query query is executeCompoundQueries in ./src/queries/virtual-query/compound-query.ts.