dbt v0.13.0 - Stephen Girard
dbt v0.13.0 provides a stable API for building new adapters and reimplements dbt’s adapters as “plugins”. We’ve used this API to reimplement the existing adapters of dbt, and also to add a couple of new ones:
Beyond adapters, this release of dbt also includes Sources which can be used to document and test source data tables.
Check out some more info about this release of dbt below!
Sources (docs)
Sources are the missing link between dbt models and source data tables. Historically, dbt users referenced source tables by typing out the qualified name of a database relation, eg:
-- models/snowplow/base/snowplow_events.sql
select *
from snowplow.event
While this system worked, it meant that dbt didn’t have any knowledge about the most crucial part of the graph: data sources! In dbt v0.13.0, you can now define and describe data sources in yml files, then reference them from your models. All told, sources work like this:
Source definition:
# models/snowplow/base/events.yml
version: 2
sources:
- name: snowplow
tables:
- name: event
Base model:
-- models/snowplow/base/snowplow_events.sql
select *
from {{ source('snowplow', 'event') }}
You can use the link between sources and models to select models in a dbt run. This selector will run all of the models that select from snowplow data.
$ dbt run --models source:snowplow+
Sources will render in the documentation website. You’ll be able to view the descriptions and tests for these sources, and they’ll also appear in the dependency graph visualization.
Source Freshness
Sources can be configured to “snapshot freshness” for your source tables. If a freshness config is provided, then dbt can optionally assert that your tables have been loaded within the boundaries of your SLAs. Check out the docs on source freshness for more information. Note: if you use dbt Cloud, you can see a visual representation of your data source freshness that looks something like this:
If you’re not using dbt Cloud, you can still run dbt source snapshot-freshness to assert the freshness constraints on your tables, but you’ll need to inspect dbt’s exit codes to determine if an error has occurred.
Model selection (docs)
In dbt v0.13.0, we added a new type of model selector: @. This selector will run all of the models downstream of the selected models, as well as the parents of those models. If you want to run all of the models that depend on a model, as well as all of the parents of those models, you can do that with:
$ dbt run --models @model_name
The selector @snowplow_web_page_context will select all of the models shown here:
require-dbt-version (docs)
The require-dbt-version config helps ensure that dbt projects are run against supported versions of dbt. This is especially useful for packages (which might contain backwards-incompatible code), or the deployment of a dbt project within a large team. If users try to run a project with an unsupported version of dbt installed, then they’ll see a helpful error like this:
This version of dbt is not supported with the 'my_project' package.
Installed version of dbt: =0.13.0
Required version of dbt for 'my_project': ['>=0.12.0', '<0.13.0']
Check the requirements for the 'my_project' package, or run dbt again with --no-version-check
Tab Completion
Check out the newly-released tab-completion script for Bash here – stave that carpal tunnel off a little longer 
Odds n’ Ends
There are lots of other helpful features and fixes in v0.13.0, check out the release notes for the full rundown.
tl;dr
- Add an output line indicating the installed version of dbt to every run
- Add support for Snowflake Key Pair Authentication (docs)
- Support SSO Authentication for Snowflake (docs)
- Add support for Snowflake’s transient tables (docs)
- Capture build timing data in
run_results.jsonto visualize project performance - Add CLI flag to toggle warnings as errors (docs)
Contributors
Thanks for your contributions to dbt!