https://dagster.io/ logo
#ask-community
Title
# ask-community
e

Eric Larson

06/22/2022, 7:55 PM
DBT circular reference in 0.15 due to ‘source’ name being the same as schema name in DBT model, resulting in Dagster asset key being the same. Appended the word ‘source’ to the source name to fix it, but would be nice to not have to do that.
🤖 1
s

sandy

06/23/2022, 12:48 AM
Thanks for reporting this, Eric. How do you avoid a collision in the database itself. Does the source version of
md_contributions
live in a different schema than the dbt-derived version of
md_contributions
? I think best practice would be for the asset keys to reflect those schemas
e

Eric Larson

06/23/2022, 2:35 PM
They both have the same schema name, but different database names. But what is happening in this case is Dagster is using the
name
of the source to generate the asset key, and which in DBT you can give it any arbritrary name. I’m not sure the best way to handle it in general to avoid naming conflicts, maybe add the literal word
source
to the key? so in my case the asset key would become
source/contribution_source/md_contributions
or maybe just use the
db/schema/table
as asset key in all cases
Copy code
sources:
  - name: contributions_source
    database: raw
    schema: contributions
    tables:
Either way it’s not a big deal once your aware of how asset key’s are generated you can plan appropriately
s

sandy

06/27/2022, 3:14 PM
Ahh - got it. I think the "right" way of handling this would be to include the database in the asset key. For dbt models, you can accomplish this by supplying a custom
node_info_to_asset_key
function when you
load_assets_from_dbt_project
. For sources, all we currently support is
source_key_prefix
, but we should support a custom function for sources as well. I filed an issue to track that: https://github.com/dagster-io/dagster/issues/8627.