"dbt found two models with the name" error - When the two models are in different projects


In my organization, we are using a single repo/multiple projects approach. In some cases, the sources/stating tables have to be duplicated across projects.

That is usually not a problem. We do have occurences of duplicated model names across projects and it works just fine - {{ ref }} seemed to be project-specific.

However, for one specific project, {{ ref }} seems to scan for models across multiple projects.

I tried comparing the the dbt_project.yml of the projects for which there is an error vs ones where duplicated model names work fine - but couldn’t find any differences.

I know there’s a two-argument variant for {{ ref }}, and that schemas can be specified in the model config - but none of that is being used in the projects where things work fine.

Any idea what could be different between the projects, that would explain the different behaviors of {{ ref }}?


Is the misbehaving project importing one of the other projects as a package? have a look in your packages.yml file

Hi Joel,

Thanks a lot for your help.

My packages.ymlfor that project is:

    - package: dbt-labs/dbt_utils
      version: 0.8.5

Any chance you’re invoking dbt from a root folder that has multiple dbt projects inside of it, and two of those projects contain the same model name?

When you run into this sort of error, dbt will show the names of the offending models:

  dbt found two models with the name "my_first_dbt_model".
  Since these resources have the same name, dbt will be unable to find the correct resource
  when looking for ref("my_first_dbt_model").
  To fix this, change the name of one of these resources:
  - model.joel_sandbox.my_first_dbt_model (models/example/my_first_dbt_model.sql)
  - model.joel_second_sandbox.my_first_dbt_model (models/my_first_dbt_model.sql)

In this case, the projects are joel_sandbox and joel_second_sandbox. If you do a search for joel_second_sandbox inside of the joel_sandbox project I imagine you should be able to find the cause?

You could also try running dbt clean to get rid of any package imports that were in packages.yml earlier but aren’t anymore.