Upgrading to v1.1
What to know before upgrading
There are no breaking changes for code in dbt projects and packages. We are committed to providing backwards compatibility for all versions 1.x. If you encounter an error upon upgrading, please let us know by opening an issue.
For maintainers of adapter plugins
We have reworked the testing suite for adapter plugin functionality. For details on the new testing suite, see: Testing a new adapter.
The abstract methods
execute now only return
connection.AdapterReponse in type hints. Previously, they could return a string. We encourage you to update your methods to return an object of class
AdapterResponse, or implement a subclass specific to your adapter. This also gives you the opportunity to add fields specific to your adapter's query execution, such as
For consumers of dbt artifacts (metadata)
The manifest schema version will be updated to v5. The only change is to the default value of
config for parsed nodes.
For users of state-based functionality, such as the
state:modified selector, recall that:
--stateartifacts must be of schema versions that are compatible with the currently running dbt version.
If you have two jobs, whereby one job compares or defers to artifacts produced by the other, you'll need to upgrade both at the same time. If there's a mismatch, dbt will alert you with this error message:
Expected a schema version of "https://schemas.getdbt.com/dbt/manifest/v5.json" in <state-path>/manifest.json, but found "https://schemas.getdbt.com/dbt/manifest/v4.json". Are you running with a different version of dbt?
New and changed documentation
Incremental models can now accept a list of multiple columns as their
unique_key, for models that need a combination of columns to uniquely identify each row. This is supported by the most common data warehouses, for incremental strategies that make use of the
unique_key config (
Generic tests can define custom names. This is useful to "prettify" the synthetic name that dbt applies automatically. It's needed to disambiguate the case when the same generic test is defined multiple times with different configurations.
Sources can define configuration inline with other
.yml properties, just like other resource types. The only supported config is
enabled; you can use this to dynamically enable/disable sources based on environment or package variables.
Advanced and experimental functionality
Fresh Rebuilds. There's a new experimental selection method in town:
source_status:fresher. Much like the
result methods, the goal is to use dbt metadata to run your DAG more efficiently. If dbt has access to previous and current results of
dbt source freshness (the
sources.json artifact), dbt can compare them to determine which sources have loaded new data, and select only resources downstream of "fresher" sources. Read more in Understanding State and CI/CD in dbt Cloud.
dbt-Jinja functions have a new landing page, and two new members:
print()function. It can be used as an alternative to
log(), and together with the
QUIETconfig, for advanced macro-driven workflows.
selected_resourcesexposes, at runtime, the list of DAG nodes selected by the current task.
Global configs include some new additions:
NO_PRINT, to control which log messages dbt prints to terminal output. For use in advanced macro-driven workflows, such as codegen.
CACHE_SELECTED_ONLYis an experimental config that can significantly speed up dbt's start-of-run preparations, in cases where you're running only a few models from a large project that manages many schemas.
For users of specific adapters
dbt-bigquery added Support for finer-grained configuration of query timeout and retry when defining your connection profile.
dbt-spark added support for a
session connection method, for use with a pySpark session, to support rapid iteration when developing advanced or experimental functionality. This connection method is not recommended for new users, and it is not supported in dbt Cloud.
Python compatibility: dbt Core officially supports Python 3.10