Open pvanderlinden opened 5 months ago
Thanks for raising this issue @pvanderlinden !
This looks similar to https://github.com/dbt-labs/dbt-core/issues/4233, but has a distinct error message.
Two questions:
--no-partial-parse
flag (like dbt docs generate --no-partial-parse
) ? It should give the same benefit as dbt clean
, but a little more ergonomically.Thanks @dbeatty10 --no-partial-parse
also works around the issue. I just figured out how to reproduce the issue.
Reproduce steps:
dbt init
my_first_dbt_model.sql
to test.my_first_dbt_model.sql
and add a second column col2
schema.yaml
file, adjust the name of the model and add the column, also adjust the ref in my_second_dbt_model.sql
custom_naming_macros.sql
to macros with the following content
{% macro generate_alias_name(custom_alias_name=none, node=none) -%}
{%- if custom_alias_name is none -%}
{%- set split_name = node.name.split('.') -%}
{%- if split_name|length > 1 -%}
{{ split_name[-1] | trim }}
{%- else -%}
{{ node.name }}
{%- endif -%}
{%- else -%}
{{ custom_alias_name | trim }}
{%- endif -%}
{%- endmacro %}
dbt docs generate
schema.yaml
and savedbt docs generate
: reproduces the bugWe have this macro in place to have tables/views in different schemas with the same name, e.g.
db.schema1.table_one
db.schema2.table_one
As we can't have two files named table_one.sql
even in a different directory, we have to prefix the files (which is included in the "ref").
Thanks for sharing these details @pvanderlinden 🏆
I was able to reproduce what you are seeing using dbt-duckdb. See below for the smallest reproducible example I could find.
The most impactful piece was:
second
) that referenced the upstream model (first
).generate_alias_name
was not needed to reproducemy_first_dbt_model
was not needed to reproducemy_second_dbt_model
was needed to reproducemodels/_models.yml
in between dbt docs generate
was needed to reproduceAssuming you already have a simple dbt_project.yml
with a dbt profile configured, here's all that is needed to reproduce:
dbt clean
mkdir -p models
cat << EOF > models/my_first_dbt_model.sql
select 1 as id
EOF
cat << EOF > models/test.my_second_dbt_model.sql
-- {{ ref("my_first_dbt_model") }}
select 2 as id
EOF
cat << EOF > models/_models.yml
models:
- name: "my_first_dbt_model"
description: My favorite color is blue
- name: "test.my_second_dbt_model"
description: My favorite color is green
EOF
dbt docs generate
cat << EOF > models/_models.yml
models:
- name: "my_first_dbt_model"
description: My favorite color is blue
- name: "test.my_second_dbt_model"
description: My favorite color is (not actually) green
EOF
dbt docs generate
A few extra observations on this issue:
dbt run
for those models.
to using a -
. This doesn't trigger the issueThese are great observations!
not directly the same issue: if you go to the table in the docs, the name is correct in the tree on the left, but the title of the page still includes the stripped of prefix.
Yep, this looks separate. If you think this is an issue, feel free to open a bug report in the dbt-docs
repo, and we can take a closer look.
Is this a new bug in dbt-core?
Current Behavior
dbt docs generate
gives the following error:while it is only defined once
Expected Behavior
generate the docs
Steps To Reproduce
dbt clean
Relevant log output
Environment
Which database adapter are you using with dbt?
snowflake
Additional Context
No response