Skip to content

Commit

Permalink
tweak to defer copy
Browse files Browse the repository at this point in the history
  • Loading branch information
coapacetic committed Nov 15, 2024
1 parent c90f8fb commit d0bf429
Showing 1 changed file with 6 additions and 4 deletions.
10 changes: 6 additions & 4 deletions website/docs/docs/cloud/about-cloud-develop-defer.md
Original file line number Diff line number Diff line change
Expand Up @@ -13,11 +13,13 @@ Both the dbt Cloud IDE and the dbt Cloud CLI enable users to natively defer to p

<Lightbox src src="/img/docs/reference/defer-diagram.png" width="50%" title="Use 'defer' to modify end-of-pipeline models by pointing to production models, instead of running everything upstream." />

By default, dbt follows these rules:
When using `--defer`, dbt Cloud will follow this order of execution for resolving the `{{ ref() }}` functions.

- dbt uses the production locations of parent models to resolve `{{ ref() }}` functions, based on metadata from the production environment.
- If a development version of a deferred model exists, dbt preferentially uses the development database location when resolving the reference.
- Passing the [`--favor-state`](/reference/node-selection/defer#favor-state) flag overrides the default behavior and _always_ resolve refs using production metadata, regardless of the presence of a development relation.
1. If a development version of a deferred relation exists, dbt preferentially uses the development database location when resolving the reference.
2. If a development version does not exist, dbt uses the staging locations of parent relations based on metadata from the staging environment.
3. If a development version AND staging version do not exist, dbt uses the production locations of parent relations based on metadata from the production environment.

**Note:** Passing the `--favor-state` flag will always resolve refs using production metadata, regardless of the presence of a development relation. This will effectively by pass step #1 above.

For a clean slate, it's a good practice to drop the development schema at the start and end of your development cycle.

Expand Down

0 comments on commit d0bf429

Please sign in to comment.