dbt-labs/dbt-core

[Feature] `state:modified.relation` should detect a change of schema in `dbt_profile.yml`

Opened this issue · 2 comments

Is this a new bug in dbt-core?

  • I believe this is a new bug in dbt-core
  • I have searched the existing issues, and I could not find an existing issue for this bug

Current Behavior

After changing only the default schema of a given target in dbt_profile.yml, nunning dbt ls --select "state:modified.relation" --state some_manifest.json does not detect the change of database relationship eventhough the diff between the 2 version of the manifest properly reflects it.

Expected Behavior

Changing the schema value of a target and running dbt ls --select "state:modified.relation" --state some_manifest.json should list all the nodes.

Steps To Reproduce

  1. run dbt parse
  2. rename target/manifest.json to prev/manifest.json
  3. update default target schema in dbt_profile,yml
  4. run dbt ls --select "state:modified.relation" --state prev

Relevant log output

No response

Environment

- OS: Windows 11 Entreprise (10.0.22621 N/A Build 22621)
- Python: 3.12.3
- dbt: 1.8.7

Which database adapter are you using with dbt?

other (mention it in "Additional Context")

Additional Context

adapter: databricks

Thanks for reaching out @AdriMarteau !

Our docs on the "state" method https://docs.getdbt.com/reference/node-selection/methods#the-state-method include the following:

state:modified.relation: Changes to database/schema/alias (the database representation of this node), irrespective of target values or generate_x_name macros

A key part those docs is trying to communicate is that target values do not count as modified. The reason is that we expect different targets (like dev vs. prod) to have different schemas and/or databases. But we don't want that to count as the model being modified.

In your particular case where you modified the target schema in the profile itself, I can see why you'd expect every model using that schema to count as modified. But I don't think it is a bug but aligns with the behavior that is currently documented. So I'm going to re-label this as a feature request for further consideration.

Thanks a lot for your reply and sorry for misreading the doc