From c90baff408f50daacdd23788952da1686c048bc6 Mon Sep 17 00:00:00 2001 From: marcelobour <117930774+marcelobour@users.noreply.github.com> Date: Wed, 11 Dec 2024 23:35:00 -0300 Subject: [PATCH 1/2] Update about in --favor-state Note While it's clear that --favor-state skips step 1, mentioning only "production metadata" without addressing staging metadata could be misleading. --- website/docs/docs/cloud/about-cloud-develop-defer.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/docs/docs/cloud/about-cloud-develop-defer.md b/website/docs/docs/cloud/about-cloud-develop-defer.md index ea059ed3e27..2cb17747111 100644 --- a/website/docs/docs/cloud/about-cloud-develop-defer.md +++ b/website/docs/docs/cloud/about-cloud-develop-defer.md @@ -19,7 +19,7 @@ When using `--defer`, dbt Cloud will follow this order of execution for resolvin 2. If a development version doesn't exist, dbt uses the staging locations of parent relations based on metadata from the staging environment. 3. If both a development and staging version doesn't 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, skipping step #1. +**Note:** Passing the `--favor-state` flag will always resolve refs using staging metadaba if it exists, else production metadata, regardless of the presence of a development relation, skipping step #1. For a clean slate, it's a good practice to drop the development schema at the start and end of your development cycle. From 8e54711e0bf073cdf435f775b25896f0b9580b4d Mon Sep 17 00:00:00 2001 From: Mirna Wong <89008547+mirnawong1@users.noreply.github.com> Date: Mon, 16 Dec 2024 13:58:52 +0000 Subject: [PATCH 2/2] Update website/docs/docs/cloud/about-cloud-develop-defer.md --- website/docs/docs/cloud/about-cloud-develop-defer.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/docs/docs/cloud/about-cloud-develop-defer.md b/website/docs/docs/cloud/about-cloud-develop-defer.md index 2cb17747111..d1685c42cba 100644 --- a/website/docs/docs/cloud/about-cloud-develop-defer.md +++ b/website/docs/docs/cloud/about-cloud-develop-defer.md @@ -19,7 +19,7 @@ When using `--defer`, dbt Cloud will follow this order of execution for resolvin 2. If a development version doesn't exist, dbt uses the staging locations of parent relations based on metadata from the staging environment. 3. If both a development and staging version doesn't 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 staging metadaba if it exists, else production metadata, regardless of the presence of a development relation, skipping step #1. +**Note:** Passing the `--favor-state` flag will always resolve refs using staging metadata if available; otherwise, it defaults to production metadata regardless of the presence of a development relation, skipping step #1. For a clean slate, it's a good practice to drop the development schema at the start and end of your development cycle.