Modelling correctness · rule catalog-materialization-drift
dbt models built differently from their config
A Metacenta review checks this under the rule Models are built as they are configured. Everything below applies whether or not you ever commission one.
What this rule checks
This rule flags a model configured as table that exists as a view, or configured as view that exists as a table. Other materialisations are not compared, because their warehouse relation types vary by adapter.
Why it matters
The project has not been rebuilt since the configuration changed. The cost and freshness everyone assumes for the model are those of the old build.
How to fix it
Rebuild the tables that no longer match their configuration. Run the model so it is rebuilt as configured, or revert the configuration to match what is built.
When it is fine to leave
A configuration change merged but not yet deployed shows up here until the next build. That is expected for a short time; a lasting gap is not.
What we need to check it
manifest.json and catalog.json, generated together by dbt docs generate. If the catalog is older than the manifest, the rule declines, because the difference could be an unbuilt change.