| title | Glossary |
|---|---|
| description | DRE terms, from Bindings and Sets to targets, sources and run artifacts. |
| section | reference |
| position | 17 |
A report paired with a Set, resolved into the queries, connection, variables and outputs for one run. A report without Sets has a default Binding.
A named database profile under connections: in profiles.yml.
Each query uses one connection; different queries in one report can use different connections.
The place a file or message is delivered, such as a local path,
object-storage bucket, email address or chat channel. Named destination profiles live under
destinations: in profiles.yml; local is built in.
The generated dependency lock file, recording exact plugin versions, checksums and macro-package commits. Commit it so another machine can resolve the same dependencies.
One occurrence of a schedule at a UTC timestamp. Its run date is the calendar date in the schedule's or report's timezone.
The writer for an output, such as csv, parquet, fixed_width or
xlsx. Formats are plugins except for the built-in message format.
A small mapping table kept in a project file, rather than in a database.
ref('name') exposes it to SQL; lookup('name') exposes its rows to Jinja.
A dependency containing reusable Jinja macros, installed from Git or a local folder. Call its macros through the package's namespace.
The machine-readable description of the loaded project, written to
target/manifest.json: reports, Bindings, sources, schedules and their dependencies.
Unlike dbt's manifest, it describes reports and deliveries rather than transformation models.
A text output rendered from query results, usually a headline or an alert. It can be delivered alone or with another output's files attached.
One formatted result of a report, with its own format, query subset and destinations. Several outputs reuse the same query execution.
An installable release containing one or more plugins, with its own version.
For example, the object_store package supplies the s3, gcs and azure_blob destinations.
A named connection or destination configuration in profiles.yml.
Each profile has target entries and may choose its own default target. DRE profiles are named
connections or destinations; they are not dbt's top-level project profile containing outputs.
The index of plugin packages and releases DRE consults when installing dependencies. A project can use the default registry or specify another index.
A YAML declaration of SQL queries and outputs. An SQL file without a report declaration is an unmanaged report, intended for quick tests.
The record of what a run did: statuses, timings, query results, output files and deliveries. It complements the manifest, which describes what can run.
A named selection of reports or Sets with a timing and optional variables. DRE describes schedules and lists occurrences; an external scheduler starts the processes.
A change to a query's result columns or types, compared with its previous successful run. Drift checks help catch output changes before delivery.
A named variant of a report, such as a client or region, with its own connection and variables. A report may override a Set's queries, tab names and outputs.
A declaration of existing database tables, accessed with source('name', 'table').
Like dbt's source declarations it identifies tables; DRE adds profile: to choose their connection
and does not execute dbt source freshness checks or tests.
A plugin that connects to a database and runs SQL, such as DuckDB or PostgreSQL. It is distinct from a source declaration, which names tables.
An environment entry, such as dev or prod,
selected from each profile's targets:. --target or DRE_TARGET selects it for every used profile.
Unlike dbt's target context, DRE's target is not the database connection; use connection.* for that.
The directory for generated files: compiled SQL, manifests, schema snapshots
and run outputs. It defaults to target/ and is unrelated to selecting the dev or prod target.
A recurrence rule, defined with cron, rrule or every.
Named entries in timings.yml let several schedules share one rule.
Previous: The manifest and run_results.json · Next: Updating DRE