-
Notifications
You must be signed in to change notification settings - Fork 966
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
clarify defer behavior #4435
clarify defer behavior #4435
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
Looks good to me! |
Both the dbt Cloud IDE and the dbt Cloud CLI allow users to natively defer to production metadata directly in their development workflows, dramatically reducing development time and warehouse spend by preventing unnecessary model builds. | ||
By default, dbt follows these rules: | ||
|
||
- Defers to the production environment when there's no development schema. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Defers to the production environment when there's no development schema. | |
- Resolves `{{ ref() }}` functions using the production locations for the parents of selected models using metadata from the production environment. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- dbt uses the production locations of parent models to resolve
{{ ref() }}
functions, based on metadata from the production environment
By default, dbt follows these rules: | ||
|
||
- Defers to the production environment when there's no development schema. | ||
- If a development schema exists, dbt will prioritize those changes, which minimizes development time and avoids unnecessary model builds. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- If a development schema exists, dbt will prioritize those changes, which minimizes development time and avoids unnecessary model builds. | |
- If a development version of a deferred model exists, dbt preferentially use that table when resolving the reference. | |
- Passing the `--favor-state` flag will override this behavior, and _always_ resolve refs using the production metadata, regardless of the presence of a development relation. |
Sophia raised a great question about defer's behavior, which users were reaching out to.
adding this info to the docs so it's clear