If you get the following warning, it’s likely that there’s something wrong in your
$ dbt compile Running with dbt=0.15.0 WARNING: Configuration paths exist in your dbt_project.yml file which do not apply to any resources. There are 1 unused configuration paths: - models.staging Found 8 models, 20 tests, 0 snapshots, 0 analyses, 269 macros, 0 operations, 3 seed files, 0 sources 11:15:10 | Concurrency: 1 threads (target='dev') 11:15:10 | 11:15:10 | Done.
There’s two common causes for this:
- Model configurations for a directory of models are not nested under the project name
- A directory has been deleted or renamed, resulting in configurations that aren’t being used
- The yaml path doesn’t match the directory path
Model configurations for a directory of models are not nested under the project name
'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 ├── staging │ ├── stg_customers.sql │ ├── stg_orders.sql │ └── stg_payments.sql ├── customers.sql └── orders.sql
The following configuration is valid:
name: jaffle_shop models: jaffle_shop: # Note this matches the `name` above staging: materialized: table # this applies to all models in our `staging` directory in our jaffle_shop project
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! staging: materialized: table # this doesn't get applied
It’s also common to forget to update the name under the
models: key to the same as the project name, leaving it as the default value,
A directory has been deleted or renamed, resulting in configurations that aren’t being used
If you’ve deleted or renamed a model, make sure you update your configurations in your
The yaml path doesn’t match the directory path
This can be easy to mess up when configuring nested subdirectories. If you’ve included your project name correctly, double check that your configuration path matches your directory structure.
For example, to configure a model at
jaffle_shop/models/staging/intermediate/*, the block would look like:
name: jaffle_shop models: jaffle_shop: # Note this matches the `name` above staging: intermediate: materialized: table
Why doesn’t dbt just use the directory structure?
While the required structure can feel unintuitive, 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.
Note, you can also apply configurations to all models (including those in other packages), by nesting it under
models, like so:
models: materialized: table # this applies to all models in all packages jaffle_shop: materialized: view # this applies to all models in our jaffle_shop project staging: materialized: table # this applies to all models in our `staging` directory in our jaffle_shop project