FAQ: I got an “unused model configurations” error message, what does this mean?

Archive
1

If you get the following warning, it’s likely that there’s something wrong in your dbt_project.yml file.

$ 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 three 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, my_new_project.

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 dbt_project.yml file.

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
7 Likes