From 39449daf6f9e4211af4b43346d2efd249140bda9 Mon Sep 17 00:00:00 2001 From: mirnawong1 Date: Mon, 13 Nov 2023 15:44:18 +0000 Subject: [PATCH 1/8] tweak defer lanuge --- .../docs/docs/cloud/about-cloud-develop-defer.md | 14 +++++--------- 1 file changed, 5 insertions(+), 9 deletions(-) diff --git a/website/docs/docs/cloud/about-cloud-develop-defer.md b/website/docs/docs/cloud/about-cloud-develop-defer.md index 1861a6d8a79..302a3548351 100644 --- a/website/docs/docs/cloud/about-cloud-develop-defer.md +++ b/website/docs/docs/cloud/about-cloud-develop-defer.md @@ -9,16 +9,12 @@ pagination_next: "docs/cloud/cloud-cli-installation" [Defer](/reference/node-selection/defer) is a powerful feature that allows developers to only build and run and test models they've edited without having to first run and build all the models that come before them (upstream parents). This is powered by using a production manifest for comparison, and dbt will resolve the `{{ ref() }}` function with upstream production artifacts. -By default, dbt follows these rules: +Both the dbt Cloud IDE and the dbt Cloud CLI allow users to natively defer to production metadata directly in their development workflows. 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. - -Both the dbt Cloud IDE and the dbt Cloud CLI allow users to natively defer to production metadata directly in their development workflows. - -For specific scenarios: -- Use [`--favor-state`](/reference/node-selection/defer#favor-state) to always use production artifacts to resolve the ref. -- If facing issues with outdated tables in the development schema, `--favor-state` is an alternative to defer. +- 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 that table when resolving the reference. +- Passing the [`--favor-state`](/reference/node-selection/defer#favor-state) flag will override this behavior and _always_ resolve refs using the production metadata, regardless of the presence of a development relation. + - If facing issues with outdated tables in the development schema, `--favor-state` is an alternative to defer. For a clean slate, it's a good practice to drop the development schema at the start and end of your development cycle. From 5467027d0d2f4c8c7d2c65d236e48a1c49397ddd Mon Sep 17 00:00:00 2001 From: mirnawong1 <89008547+mirnawong1@users.noreply.github.com> Date: Mon, 13 Nov 2023 15:49:59 +0000 Subject: [PATCH 2/8] Update website/docs/docs/cloud/about-cloud-develop-defer.md Co-authored-by: dave-connors-3 <73915542+dave-connors-3@users.noreply.github.com> --- 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 302a3548351..f0fcaec9f39 100644 --- a/website/docs/docs/cloud/about-cloud-develop-defer.md +++ b/website/docs/docs/cloud/about-cloud-develop-defer.md @@ -12,7 +12,7 @@ pagination_next: "docs/cloud/cloud-cli-installation" Both the dbt Cloud IDE and the dbt Cloud CLI allow users to natively defer to production metadata directly in their development workflows. By default, dbt follows these rules: - 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 that table when resolving the reference. +- If a development version of a deferred model exists, dbt preferentially uses that database location when resolving the reference. - Passing the [`--favor-state`](/reference/node-selection/defer#favor-state) flag will override this behavior and _always_ resolve refs using the production metadata, regardless of the presence of a development relation. - If facing issues with outdated tables in the development schema, `--favor-state` is an alternative to defer. From caa28652e56f0bff48a13029262c6a035624ad16 Mon Sep 17 00:00:00 2001 From: mirnawong1 <89008547+mirnawong1@users.noreply.github.com> Date: Mon, 13 Nov 2023 15:52:45 +0000 Subject: [PATCH 3/8] Update website/docs/docs/cloud/about-cloud-develop-defer.md Co-authored-by: dave-connors-3 <73915542+dave-connors-3@users.noreply.github.com> --- website/docs/docs/cloud/about-cloud-develop-defer.md | 1 - 1 file changed, 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 f0fcaec9f39..fca09530f62 100644 --- a/website/docs/docs/cloud/about-cloud-develop-defer.md +++ b/website/docs/docs/cloud/about-cloud-develop-defer.md @@ -14,7 +14,6 @@ Both the dbt Cloud IDE and the dbt Cloud CLI allow users to natively defer to pr - 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 that database location when resolving the reference. - Passing the [`--favor-state`](/reference/node-selection/defer#favor-state) flag will override this behavior and _always_ resolve refs using the production metadata, regardless of the presence of a development relation. - - If facing issues with outdated tables in the development schema, `--favor-state` is an alternative to defer. For a clean slate, it's a good practice to drop the development schema at the start and end of your development cycle. From 2ea6ba1b02fd369d7ff33cd1e5b20fd08f8b6983 Mon Sep 17 00:00:00 2001 From: mirnawong1 <89008547+mirnawong1@users.noreply.github.com> Date: Mon, 13 Nov 2023 15:53:55 +0000 Subject: [PATCH 4/8] Update website/docs/docs/cloud/about-cloud-develop-defer.md --- website/docs/docs/cloud/about-cloud-develop-defer.md | 4 +++- 1 file changed, 3 insertions(+), 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 fca09530f62..d261a990b90 100644 --- a/website/docs/docs/cloud/about-cloud-develop-defer.md +++ b/website/docs/docs/cloud/about-cloud-develop-defer.md @@ -9,7 +9,9 @@ pagination_next: "docs/cloud/cloud-cli-installation" [Defer](/reference/node-selection/defer) is a powerful feature that allows developers to only build and run and test models they've edited without having to first run and build all the models that come before them (upstream parents). This is powered by using a production manifest for comparison, and dbt will resolve the `{{ ref() }}` function with upstream production artifacts. -Both the dbt Cloud IDE and the dbt Cloud CLI allow users to natively defer to production metadata directly in their development workflows. By default, dbt follows these rules: +Both the dbt Cloud IDE and the dbt Cloud CLI allow users to natively defer to production metadata directly in their development workflows. + +By default, dbt follows these rules: - 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 that database location when resolving the reference. From 9a9118b827f42ea7983027ec62cd081ca2659063 Mon Sep 17 00:00:00 2001 From: mirnawong1 <89008547+mirnawong1@users.noreply.github.com> Date: Mon, 13 Nov 2023 17:46:04 +0000 Subject: [PATCH 5/8] Update website/docs/docs/cloud/about-cloud-develop-defer.md Co-authored-by: Leona B. Campbell <3880403+runleonarun@users.noreply.github.com> --- 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 d261a990b90..0c961cf0db1 100644 --- a/website/docs/docs/cloud/about-cloud-develop-defer.md +++ b/website/docs/docs/cloud/about-cloud-develop-defer.md @@ -15,7 +15,7 @@ By default, dbt follows these rules: - 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 that database location when resolving the reference. -- Passing the [`--favor-state`](/reference/node-selection/defer#favor-state) flag will override this behavior and _always_ resolve refs using the production metadata, regardless of the presence of a development relation. +- 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. For a clean slate, it's a good practice to drop the development schema at the start and end of your development cycle. From e24ee7074cd5ae781d4a8027d116b49c6b6842f7 Mon Sep 17 00:00:00 2001 From: mirnawong1 <89008547+mirnawong1@users.noreply.github.com> Date: Mon, 13 Nov 2023 17:46:10 +0000 Subject: [PATCH 6/8] Update website/docs/docs/cloud/about-cloud-develop-defer.md Co-authored-by: Leona B. Campbell <3880403+runleonarun@users.noreply.github.com> --- 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 0c961cf0db1..5d3b76c7430 100644 --- a/website/docs/docs/cloud/about-cloud-develop-defer.md +++ b/website/docs/docs/cloud/about-cloud-develop-defer.md @@ -14,7 +14,7 @@ Both the dbt Cloud IDE and the dbt Cloud CLI allow users to natively defer to pr By default, dbt follows these rules: - 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 that database location when resolving the reference. +- 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. For a clean slate, it's a good practice to drop the development schema at the start and end of your development cycle. From c5c4a69d028595eb0fd556475a493afaf5bd2de9 Mon Sep 17 00:00:00 2001 From: mirnawong1 <89008547+mirnawong1@users.noreply.github.com> Date: Mon, 13 Nov 2023 17:46:18 +0000 Subject: [PATCH 7/8] Update website/docs/docs/cloud/about-cloud-develop-defer.md Co-authored-by: Leona B. Campbell <3880403+runleonarun@users.noreply.github.com> --- 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 5d3b76c7430..0158ed8a7eb 100644 --- a/website/docs/docs/cloud/about-cloud-develop-defer.md +++ b/website/docs/docs/cloud/about-cloud-develop-defer.md @@ -7,7 +7,7 @@ pagination_next: "docs/cloud/cloud-cli-installation" --- -[Defer](/reference/node-selection/defer) is a powerful feature that allows developers to only build and run and test models they've edited without having to first run and build all the models that come before them (upstream parents). This is powered by using a production manifest for comparison, and dbt will resolve the `{{ ref() }}` function with upstream production artifacts. +[Defer](/reference/node-selection/defer) is a powerful feature that allows developers to only build and run and test models they've edited without having to first run and build all the models that come before them (upstream parents). dbt powers this by using a production manifest for comparison, and resolves the `{{ ref() }}` function with upstream production artifacts. Both the dbt Cloud IDE and the dbt Cloud CLI allow users to natively defer to production metadata directly in their development workflows. From 2cba7d1baac86cf4796158f748b57b1395646163 Mon Sep 17 00:00:00 2001 From: mirnawong1 <89008547+mirnawong1@users.noreply.github.com> Date: Mon, 13 Nov 2023 17:46:25 +0000 Subject: [PATCH 8/8] Update website/docs/docs/cloud/about-cloud-develop-defer.md Co-authored-by: Leona B. Campbell <3880403+runleonarun@users.noreply.github.com> --- 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 0158ed8a7eb..37bfaacfd0c 100644 --- a/website/docs/docs/cloud/about-cloud-develop-defer.md +++ b/website/docs/docs/cloud/about-cloud-develop-defer.md @@ -9,7 +9,7 @@ pagination_next: "docs/cloud/cloud-cli-installation" [Defer](/reference/node-selection/defer) is a powerful feature that allows developers to only build and run and test models they've edited without having to first run and build all the models that come before them (upstream parents). dbt powers this by using a production manifest for comparison, and resolves the `{{ ref() }}` function with upstream production artifacts. -Both the dbt Cloud IDE and the dbt Cloud CLI allow users to natively defer to production metadata directly in their development workflows. +Both the dbt Cloud IDE and the dbt Cloud CLI enable users to natively defer to production metadata directly in their development workflows. By default, dbt follows these rules: