dbt / Intermediate: history and controlled workflows / Lesson 11

Selectors and controlled execution scope

Express graph scope precisely and preview selected resources before authorizing expensive or destructive work.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Read ancestor, descendant, union and intersection selection.
Separate model selection, test inclusion and database authorization.

Selection is a set operation over declared resources

A library project may contain staging, facts and daily reports with different tags and materializations. A selector names a set of graph resources; it does not change their business meaning or database permissions. Prefixing a model with + includes supported ancestors, while a suffix + includes descendants under documented graph syntax. Independent nodes outside that graph path are not automatically included. Specify the desired prerequisite and dependent scope before choosing punctuation. A small change in a selector can turn one-model work into a broad rebuild, so review selection with the same care as SQL.

Preview the names rather than inferring them from a command

The illustrative list command would request the fct_loans descendants while restricting displayed resource type to models. It is not executed here. dbt commands have different supported flags and indirect test behavior, so a model-only preview is not automatically the complete build plan including tests, seeds or snapshots. Record the resolved resource names and effective configs in an independently authorized review. A selector that matches nothing should be an explained result, not silently treated as a successful deployment. Preserve exact target and state context with any preview evidence.

text Illustrative technical example; logical results are reasoned, not engine-tested.

dbt ls --select fct_loans+ --resource-type model

Illustrative CLI text only. It is not run, and its resource-type filter intentionally omits non-model resources from the displayed set.

Make a reusable intersection readable

The YAML selector means resources that have tag nightly and materialized config table. It does not mean either condition independently. A named selector centralizes intent so orchestration does not carry several nearly identical command strings. Keep the tag assignment and effective materialization under review; a config change can alter the selected set even when the selector file is unchanged. Avoid treating tags as data-access security or business ownership enforcement. The fragment assumes suitable tagged resources exist and creates no job, schedule or warehouse operation.

yaml Illustrative technical example; logical results are reasoned, not engine-tested.

selectors:
  - name: nightly_tables
    definition:
      intersection:
        - method: tag
          value: nightly
        - method: config.materialized
          value: table

A selectors.yml intersection for review. Actual selected nodes depend on project metadata and the command context.

Indirect tests have their own selection semantics

A selected model can bring associated tests into supported commands according to indirect-selection policy. Tests referencing several parents can behave differently under eager, cautious or other documented modes. Excluding a resource from execution does not necessarily prevent another selected model from reading its existing relation. Distinguish “not built now” from “not referenced” and “not authorized.” Review selected resources, resolved inputs and runtime grants together. A narrow selector cannot make a broadly privileged credential safe by itself, and a build failure does not imply all earlier selected nodes were rolled back atomically.

State selection depends on a trustworthy comparison baseline

state:modified compares project metadata with a prior artifact under documented compatibility rules; it is not a generic check of every changed source row. Adding descendants can widen the execution set, and deferral can change where unselected references resolve. Keep the comparison manifest separate from new output artifacts so it is not overwritten while being used. Validate its project, version and environment provenance. This course runs no list, build, state or defer command. Its local graph model can verify ancestor and descendant sets only, not dbt’s full selector parser or a warehouse access decision.

Common errors and fixes

A suffix plus is read as prerequisites only

Why it happens: Ancestor and descendant directions were reversed.
How to fix it: Inspect the graph and preview the exact selected resources.
Prevent it next time: Keep tiny selector examples with known expected sets.

A tag intersection is implemented as a union

Why it happens: Either-condition selection replaced the intended both-condition rule.
How to fix it: Use a clear named intersection and verify membership.
Prevent it next time: Test one resource matching only each individual condition.

No selected models is reported as a successful release

Why it happens: An empty selector result was not reconciled with expected scope.
How to fix it: Review paths, tags, configs and state baseline before execution.
Prevent it next time: Require explained selection counts and names in release evidence.

Check your understanding

1. In staging→fact→report, what does fact+ include conceptually?

Show worked solution

It includes fact and its descendants such as report under the documented graph selection. It does not include staging merely because staging is an ancestor. Preview actual resources and separately review associated test behavior and existing upstream relations.

2. Does excluding a source model guarantee selected SQL cannot read its existing table?