You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Current State
During manifest parsing, dbt raises a compilation error if dbt detects two (unversioned) models with the same name:
Compilation Error
dbt found two models with the name "model_a".
Since these resources have the same name, dbt will be unable to find the correct resource
when looking for ref("model_a").
To fix this, change the name of one of these resources:
- model.project_b.model_a (models/model_a.sql)
- model.project_a.model_a (models/model_a.sql)
This is so that refs originating from any project (project_a, project_b, root_project) don’t have an ambiguous resolution for ref('model_a')
Proposal
To support installing multiple packages as projects, we should relax this uniqueness constraint and allow duplicate model (or other ref-able resource) names across packages. Model name uniqueness should still be enforced within a single project.
ref resolution
Assuming a model named model_a is defined in project_a, and project_b, both of which are installed in a root project:
model in project_a has a ref('model_a') → ref resolves to model.project_a.model_a
model in project_b has a ref('model_a') → ref resolves to model.project_b.model_a
model in root (running) project has a ref('model_a')
if it defines its own model_a node → model.root_project.model_a
otherwise: raise an error indicating an ambiguous ref
The first two scenarios already work! But the third is broken because dbt resolves “model_a” to an arbitrary project.
** Notes **
Bypassing the initial error can lead to a totally legitimate error aiming to prevent clobbering in the database:
Compilation Error
dbt found two resources with the database representation ""dbt"."test_arky"."model_a"".
dbt cannot create two resources with identical database representations. To fix this,
change the configuration of one of these resources:
- model.project_b.model_a (models/model_a.sql)
- model.project_a.model_a (models/model_a.sql)
In this case, the root project should define configurations in its dbt_project.yml to ensure no alias clobbering occurs. For example:
Current State
During manifest parsing, dbt raises a compilation error if dbt detects two (unversioned) models with the same name:
This is so that refs originating from any project (project_a, project_b, root_project) don’t have an ambiguous resolution for ref('model_a')
Proposal
To support installing multiple packages as projects, we should relax this uniqueness constraint and allow duplicate model (or other ref-able resource) names across packages. Model name uniqueness should still be enforced within a single project.
ref resolution
Assuming a model named
model_a
is defined inproject_a
, andproject_b
, both of which are installed in a root project:ref('model_a')
→ ref resolves tomodel.project_a.model_a
ref('model_a')
→ ref resolves tomodel.project_b.model_a
ref('model_a')
model.root_project.model_a
The first two scenarios already work! But the third is broken because dbt resolves “model_a” to an arbitrary project.
** Notes **
Bypassing the initial error can lead to a totally legitimate error aiming to prevent clobbering in the database:
In this case, the root project should define configurations in its dbt_project.yml to ensure no alias clobbering occurs. For example:
The text was updated successfully, but these errors were encountered: