One of the most common pitfalls for new dbt users is configuring models (or seeds) correctly in the
dbt_project.yml file (see documentation).
To apply configurations to models within your project, you need to nest configurations under the project name, and then use the directory path to apply fine-grained configurations.
For example, consider a project, called
jaffle_shop with the following structure:
. ├── dbt_project.yml └── models ├── base │ ├── base_customers.sql │ ├── base_orders.sql │ └── base_payments.sql ├── customers.sql └── orders.sql
The following configuration is valid:
name: jaffle_shop models: jaffle_shop: # Note this matches the `name` above base: materialized: view base_customers: materialized: table customers: materialized: table
The most common mistake people make is to omit the package name, like so:
name: jaffle_shop models: # MISSING PROJECT NAME, DON'T DO THIS! # None of the following configurations will be applied base: materialized: view base_customers: materialized: table customers: materialized: view
Note, you can also apply configurations to all models (including those in other packages), by nesting it under
models, like so:
models: materialized: table
Why doesn’t dbt just use the directory structure?
While the required structure is unintuitive and can lead to errors, it exists for a good reason (promise!).
Nesting configurations under the project name enables dbt users who are using packages within their project to configure those packages from a single yml file. For example, if an organization is using the Snowplow package, they would be able to configure how dbt builds the Snowplow package within the
dbt_project.yml file of their own project, allowing greater flexibility.
Since it is confusing, as of v0.12.0, dbt will warn you during compilation when there are configurations in your
dbt_project.yml file that do not apply to a model or seed.