From 0a8b4bff972c67d7c8950f1dd7e19cdc1a97529e Mon Sep 17 00:00:00 2001 From: mirnawong1 Date: Wed, 30 Aug 2023 13:06:09 +0100 Subject: [PATCH 01/25] clarify macro aren't support in project.yml file --- website/docs/reference/dbt_project.yml.md | 5 +- website/docs/reference/macro-properties.md | 4 +- .../docs/reference/resource-configs/docs.md | 78 ++++++++++++++++--- 3 files changed, 72 insertions(+), 15 deletions(-) diff --git a/website/docs/reference/dbt_project.yml.md b/website/docs/reference/dbt_project.yml.md index 59541a81256..6009033d557 100644 --- a/website/docs/reference/dbt_project.yml.md +++ b/website/docs/reference/dbt_project.yml.md @@ -18,12 +18,13 @@ By default, dbt will look for `dbt_project.yml` in your current working director -The following is a list of all available configurations in the `dbt_project.yml` file. - :::info YAML syntax + dbt uses YAML in a few different places. If you're new to YAML, it would be worth taking the time to learn how arrays, dictionaries and strings are represented. ::: +The following is a list of all available configurations in the `dbt_project.yml` file. Something to note, [Macro properties](/reference/macro-properties) aren't supported in the `dbt_project.yml` file: + ```yml diff --git a/website/docs/reference/macro-properties.md b/website/docs/reference/macro-properties.md index 91ba52de9ca..3b755cd0107 100644 --- a/website/docs/reference/macro-properties.md +++ b/website/docs/reference/macro-properties.md @@ -2,9 +2,9 @@ title: Macro properties --- -Macro properties can be declared in `.yml` files. +Macro properties can be declared in `.yml` files, except in the `dbt_project.yml` files. -You can name these files `whatever_you_want.yml`, and nest them arbitrarily deeply in subfolders. +You can name these files `whatever_you_want.yml`, and nest them arbitrarily deeply in sub-folders. diff --git a/website/docs/reference/resource-configs/docs.md b/website/docs/reference/resource-configs/docs.md index d94b975683d..dff58be8931 100644 --- a/website/docs/reference/resource-configs/docs.md +++ b/website/docs/reference/resource-configs/docs.md @@ -17,10 +17,28 @@ default_value: {show: true} { label: 'Macros', value: 'macros', }, ] }> + +You can use the docs property in YAML files, including the `dbt_project.yml`: + + + +```yml +name: "your_dbt_project_name" +version: "1.0.0" +config-version: 2 + +models: + - name: model_name + docs: + show: true | false +``` + + + ```yml version: 2 @@ -28,7 +46,6 @@ models: - name: model_name docs: show: true | false - ``` @@ -43,6 +60,22 @@ This property is not implemented for sources. +You can use the docs property in YAML files, including the `dbt_project.yml`: + + + +```yml +name: "your_dbt_project_name" +version: "1.0.0" +config-version: 2 + +seeds: + - name: seed_name + docs: + show: true | false +``` + + ```yml @@ -52,15 +85,29 @@ seeds: - name: seed_name docs: show: true | false - ``` - +You can use the docs property in YAML files, including the `dbt_project.yml`: + + + +```yml +name: "your_dbt_project_name" +version: "1.0.0" +config-version: 2 + +snapshots: + - name: snapshot_name + docs: + show: true | false +``` + + ```yml @@ -70,15 +117,29 @@ snapshots: - name: snapshot_name docs: show: true | false - ``` - +You can use the docs property in YAML files, including the `dbt_project.yml`: + + + +```yml +name: "your_dbt_project_name" +version: "1.0.0" +config-version: 2 + +analyses: + - name: analysis_name + docs: + show: true | false +``` + + ```yml @@ -89,16 +150,13 @@ analyses: docs: show: true | false ``` - - +You can use the docs property in YAML files, _except_ in `dbt_project.yml`. [Macro properties](/reference/macro-properties) _are not_ supported in the `dbt_project.yml` file. @@ -109,9 +167,7 @@ macros: - name: macro_name docs: show: true | false - ``` - From cda991a8909f1e68c8b1541ad6bafa39e6695c27 Mon Sep 17 00:00:00 2001 From: mirnawong1 Date: Thu, 31 Aug 2023 17:26:00 +0100 Subject: [PATCH 02/25] add snippet and rephrase --- website/docs/reference/analysis-properties.md | 4 +++- website/docs/reference/configs-and-properties.md | 7 +++++-- website/docs/reference/exposure-properties.md | 6 +++++- website/docs/reference/macro-properties.md | 7 +++++-- website/docs/reference/source-properties.md | 10 +++++++--- website/snippets/_config-prop-callout.md | 1 + 6 files changed, 26 insertions(+), 9 deletions(-) create mode 100644 website/snippets/_config-prop-callout.md diff --git a/website/docs/reference/analysis-properties.md b/website/docs/reference/analysis-properties.md index 008da70f9db..c43819c57b9 100644 --- a/website/docs/reference/analysis-properties.md +++ b/website/docs/reference/analysis-properties.md @@ -2,7 +2,9 @@ title: Analysis properties --- -We recommend you define analysis properties in your `analyses/` directory, which is illustrated in the [`analysis-paths`](/reference/project-configs/analysis-paths) configuration. +import PropsCallout from '/snippets/_config-prop-callout.md'; + +We recommend you define analysis properties in your `analyses/` directory, which is illustrated in the [`analysis-paths`](/reference/project-configs/analysis-paths) configuration.
You can name these files `whatever_you_want.yml`, and nest them arbitrarily deeply in subfolders within the `analyses/` or `models/` directory. diff --git a/website/docs/reference/configs-and-properties.md b/website/docs/reference/configs-and-properties.md index c2ad5b77629..76297f695ca 100644 --- a/website/docs/reference/configs-and-properties.md +++ b/website/docs/reference/configs-and-properties.md @@ -64,15 +64,18 @@ Previous versions of the docs referred to these as `schema.yml` files — we've ### Which properties are _not_ also configs? -dbt has the ability to define node configs in `.yml` files, in addition to `config()` blocks and `dbt_project.yml`. But the reverse isn't always true: there are some things in `.yml` files that can _only_ be defined there. +In dbt, you can define node configs in `.yml` files, in addition to `config()` blocks and `dbt_project.yml`. However, some properties are exclusive to `.yml` files. + Certain properties are special, because: + - They have a unique Jinja rendering context - They create new project resources - They don't make sense as hierarchical configuration - They're older properties that haven't yet been redefined as configs -These properties are: +This means "configs" can be set for multiple resources at once in the `dbt_project.yml` file, while "properties" can only be set for one resource at a time. The following properties _cannot_ be configured from `dbt_project.yml`: + - [`description`](/reference/resource-properties/description) - [`tests`](/reference/resource-properties/tests) - [`docs`](/reference/resource-configs/docs) diff --git a/website/docs/reference/exposure-properties.md b/website/docs/reference/exposure-properties.md index aaed2a20a09..7a7b9f18790 100644 --- a/website/docs/reference/exposure-properties.md +++ b/website/docs/reference/exposure-properties.md @@ -8,7 +8,11 @@ description: "Read this guide to understand exposure properties in dbt." - [Declaring resource properties](/reference/configs-and-properties) ## Overview -Exposures are defined in `.yml` files nested under an `exposures:` key. You may define `exposures` in YAML files that also define define `sources` or `models`. + +import PropsCallout from '/snippets/_config-prop-callout.md'; + +Exposures are defined in `.yml` files nested under an `exposures:` key. You may define `exposures` in YAML files that also define `sources` or `models`, except in the `dbt_project.yml` files.
+ You can name these files `whatever_you_want.yml`, and nest them arbitrarily deeply in subfolders within the `models/` directory. diff --git a/website/docs/reference/macro-properties.md b/website/docs/reference/macro-properties.md index 3b755cd0107..2ef2a2fb82e 100644 --- a/website/docs/reference/macro-properties.md +++ b/website/docs/reference/macro-properties.md @@ -1,10 +1,13 @@ --- title: Macro properties +id: macro-properties --- -Macro properties can be declared in `.yml` files, except in the `dbt_project.yml` files. +import PropsCallout from '/snippets/_config-prop-callout.md'; -You can name these files `whatever_you_want.yml`, and nest them arbitrarily deeply in sub-folders. +Macro properties can be declared in `.yml` files, except in the `dbt_project.yml` files.
+ + You can name these files `whatever_you_want.yml`, and nest them arbitrarily deeply in sub-folders: diff --git a/website/docs/reference/source-properties.md b/website/docs/reference/source-properties.md index d20ef5f2877..9388d60a2e9 100644 --- a/website/docs/reference/source-properties.md +++ b/website/docs/reference/source-properties.md @@ -1,5 +1,5 @@ --- -title: "About source properties" +title: "Source properties" description: "Learn how to use source properties in dbt." --- @@ -8,9 +8,13 @@ description: "Learn how to use source properties in dbt." - [Declaring resource properties](/reference/configs-and-properties) ## Overview -Source properties can be declared in `.yml` files in your `models/` directory (as defined by the [`model-paths` config](/reference/project-configs/model-paths)). -You can name these files `whatever_you_want.yml`, and nest them arbitrarily deeply in subfolders within the `models/` directory. +import PropsCallout from '/snippets/_config-prop-callout.md'; + +Source properties can be declared in `.yml` files in your `models/` directory (as defined by the [`model-paths` config](/reference/project-configs/model-paths)), except in the `dbt_project.yml` files.
+ + +You can name these files `whatever_you_want.yml`, and nest them arbitrarily deeply in subfolders within the `models/` directory: diff --git a/website/snippets/_config-prop-callout.md b/website/snippets/_config-prop-callout.md new file mode 100644 index 00000000000..bfb74e1524d --- /dev/null +++ b/website/snippets/_config-prop-callout.md @@ -0,0 +1 @@ +This is because you can set "configs" for many resources in dbt_project.yml, while you can only set "properties" one resource at a time.

Since {props.title} are "properties", this means you cannot configure it from dbt_project.yml. Refer to Configs and properties for more info. From 66ff1df9d87b7b40f5a339257b854d176db8e772 Mon Sep 17 00:00:00 2001 From: mirnawong1 <89008547+mirnawong1@users.noreply.github.com> Date: Thu, 31 Aug 2023 17:28:08 +0100 Subject: [PATCH 03/25] Update dbt_project.yml.md --- website/docs/reference/dbt_project.yml.md | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/website/docs/reference/dbt_project.yml.md b/website/docs/reference/dbt_project.yml.md index 6009033d557..73c661a9751 100644 --- a/website/docs/reference/dbt_project.yml.md +++ b/website/docs/reference/dbt_project.yml.md @@ -4,7 +4,7 @@ -Every [dbt project](/docs/build/projects) needs a `dbt_project.yml` file — this is how dbt knows a directory is a dbt project. It also contains important information that tells dbt how to operate on your project. +Every [dbt project](/docs/build/projects) needs a `dbt_project.yml` file — this is how dbt knows a directory is a dbt project. It also contains important information that tells dbt how to operate your project. @@ -20,10 +20,14 @@ By default, dbt will look for `dbt_project.yml` in your current working director :::info YAML syntax -dbt uses YAML in a few different places. If you're new to YAML, it would be worth taking the time to learn how arrays, dictionaries and strings are represented. +dbt uses YAML in a few different places. If you're new to YAML, it would be worth taking the time to learn how arrays, dictionaries, and strings are represented. ::: -The following is a list of all available configurations in the `dbt_project.yml` file. Something to note, [Macro properties](/reference/macro-properties) aren't supported in the `dbt_project.yml` file: +The following example is a list of all available configurations in the `dbt_project.yml` file. Something to note, the following properties aren't supported in in the `dbt_project.yml` file: + +- [Macro properties](/reference/macro-properties) +- [Analysis properties](/reference/analysis-properties) +- [Semantic model configs](/docs/build/semantic-models) From b163c5bc0576dc69dd967ffb465d86c0926e9b57 Mon Sep 17 00:00:00 2001 From: mirnawong1 <89008547+mirnawong1@users.noreply.github.com> Date: Thu, 31 Aug 2023 17:28:48 +0100 Subject: [PATCH 04/25] Update website/docs/reference/macro-properties.md Co-authored-by: Matt Shaver <60105315+matthewshaver@users.noreply.github.com> --- website/docs/reference/macro-properties.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/docs/reference/macro-properties.md b/website/docs/reference/macro-properties.md index 3b755cd0107..9e59ca58705 100644 --- a/website/docs/reference/macro-properties.md +++ b/website/docs/reference/macro-properties.md @@ -4,7 +4,7 @@ title: Macro properties Macro properties can be declared in `.yml` files, except in the `dbt_project.yml` files. -You can name these files `whatever_you_want.yml`, and nest them arbitrarily deeply in sub-folders. +You can name these files `whatever_you_want.yml` and nest them arbitrarily deep in sub-folders. From ddd2c636dca4bd307fc9a942b248b65aec6ce8bc Mon Sep 17 00:00:00 2001 From: mirnawong1 <89008547+mirnawong1@users.noreply.github.com> Date: Thu, 31 Aug 2023 17:28:55 +0100 Subject: [PATCH 05/25] Update website/docs/reference/macro-properties.md Co-authored-by: Matt Shaver <60105315+matthewshaver@users.noreply.github.com> --- website/docs/reference/macro-properties.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/docs/reference/macro-properties.md b/website/docs/reference/macro-properties.md index 9e59ca58705..329a5a94a9f 100644 --- a/website/docs/reference/macro-properties.md +++ b/website/docs/reference/macro-properties.md @@ -2,7 +2,7 @@ title: Macro properties --- -Macro properties can be declared in `.yml` files, except in the `dbt_project.yml` files. +Macro properties can be declared in any `.yml` file except for the `dbt_project.yml` file. You can name these files `whatever_you_want.yml` and nest them arbitrarily deep in sub-folders. From 6d8ce4eab93834bb1319c0c1ae14bac110037d52 Mon Sep 17 00:00:00 2001 From: mirnawong1 Date: Thu, 31 Aug 2023 17:32:00 +0100 Subject: [PATCH 06/25] update lang --- website/docs/reference/source-properties.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/docs/reference/source-properties.md b/website/docs/reference/source-properties.md index 9388d60a2e9..4dee14d27f4 100644 --- a/website/docs/reference/source-properties.md +++ b/website/docs/reference/source-properties.md @@ -11,7 +11,7 @@ description: "Learn how to use source properties in dbt." import PropsCallout from '/snippets/_config-prop-callout.md'; -Source properties can be declared in `.yml` files in your `models/` directory (as defined by the [`model-paths` config](/reference/project-configs/model-paths)), except in the `dbt_project.yml` files.
+Source properties can be declared in any `.yml` file in your `models/` directory (as defined by the [`model-paths` config](/reference/project-configs/model-paths)), except for the `dbt_project.yml` file.
You can name these files `whatever_you_want.yml`, and nest them arbitrarily deeply in subfolders within the `models/` directory: From 9a9627afbf3f86094774b3dd93b068c756f7863d Mon Sep 17 00:00:00 2001 From: mirnawong1 Date: Wed, 6 Sep 2023 12:04:54 +0100 Subject: [PATCH 07/25] tweak snippet and add versionblock --- website/docs/reference/dbt_project.yml.md | 18 ++++++++++++++++++ website/docs/reference/macro-properties.md | 4 +++- website/snippets/_config-prop-callout.md | 2 +- 3 files changed, 22 insertions(+), 2 deletions(-) diff --git a/website/docs/reference/dbt_project.yml.md b/website/docs/reference/dbt_project.yml.md index 73c661a9751..1e63beae082 100644 --- a/website/docs/reference/dbt_project.yml.md +++ b/website/docs/reference/dbt_project.yml.md @@ -23,11 +23,29 @@ By default, dbt will look for `dbt_project.yml` in your current working director dbt uses YAML in a few different places. If you're new to YAML, it would be worth taking the time to learn how arrays, dictionaries, and strings are represented. ::: + + + +The following example is a list of all available configurations in the `dbt_project.yml` file. Something to note, the following properties aren't supported in in the `dbt_project.yml` file: + +- [Exposure properties](/reference/exposure-properties) +- [Macro properties](/reference/macro-properties) +- [Analysis properties](/reference/analysis-properties) +- [Source properties](/reference/source-properties) + + + + + The following example is a list of all available configurations in the `dbt_project.yml` file. Something to note, the following properties aren't supported in in the `dbt_project.yml` file: +- [Exposure properties](/reference/exposure-properties) - [Macro properties](/reference/macro-properties) - [Analysis properties](/reference/analysis-properties) - [Semantic model configs](/docs/build/semantic-models) +- [Source properties](/reference/source-properties) + + diff --git a/website/docs/reference/macro-properties.md b/website/docs/reference/macro-properties.md index 5fdcea317c8..348eaf6139d 100644 --- a/website/docs/reference/macro-properties.md +++ b/website/docs/reference/macro-properties.md @@ -3,7 +3,9 @@ title: Macro properties id: macro-properties --- -Macro properties can be declared in any `.yml` file except for the `dbt_project.yml` file.
+import PropsCallout from '/snippets/_config-prop-callout.md'; + +Macro properties can be declared in any `.yml` file, except for the `dbt_project.yml` file. You can name these files `whatever_you_want.yml` and nest them arbitrarily deep in sub-folders. diff --git a/website/snippets/_config-prop-callout.md b/website/snippets/_config-prop-callout.md index bfb74e1524d..a0b7e45a1de 100644 --- a/website/snippets/_config-prop-callout.md +++ b/website/snippets/_config-prop-callout.md @@ -1 +1 @@ -This is because you can set "configs" for many resources in dbt_project.yml, while you can only set "properties" one resource at a time.

Since {props.title} are "properties", this means you cannot configure it from dbt_project.yml. Refer to Configs and properties for more info. +This is because you can set "configs" for many resources in dbt_project.yml, while you can only set "properties" one resource at a time.

Since {props.title} are "properties", this means you cannot configure it from dbt_project.yml. Refer to Configs and properties for more info. From a56d9a868b1e3a58e27bccc816d9626ef33127b6 Mon Sep 17 00:00:00 2001 From: mirnawong1 Date: Wed, 6 Sep 2023 12:19:04 +0100 Subject: [PATCH 08/25] remove break --- website/docs/docs/build/semantic-models.md | 16 +++++++++++++++- website/docs/reference/dbt_project.yml.md | 6 ++++-- website/docs/reference/exposure-properties.md | 2 +- website/snippets/_config-prop-callout.md | 2 +- 4 files changed, 21 insertions(+), 5 deletions(-) diff --git a/website/docs/docs/build/semantic-models.md b/website/docs/docs/build/semantic-models.md index bb56bd212e6..ca430ae5437 100644 --- a/website/docs/docs/build/semantic-models.md +++ b/website/docs/docs/build/semantic-models.md @@ -8,11 +8,25 @@ sidebar_label: Semantic models tags: [Metrics, Semantic Layer] --- +import PropsCallout from '/snippets/_config-prop-callout.md'; + Semantic models serve as the foundation for defining data in MetricFlow, which powers the dbt Semantic Layer. You can think of semantic models as nodes in your semantic graph, connected via entities as edges. MetricFlow takes semantic models defined in YAML configuration files as inputs and creates a semantic graph that can be used to query metrics. Each semantic model corresponds to a dbt model in your DAG. Therefore you will have one YAML config for each semantic model in your dbt project. You can create multiple semantic models out of a single dbt model, as long as you give each semantic model a unique name. -You can configure semantic models in your dbt project directory in a `YAML` file. Depending on your project structure, you can nest semantic models under a `metrics:` folder or organize them under project sources. + + +You can configure semantic models in your dbt project directory in a `YAML` file, _except_ the `dbt_project.yml` file. Depending on your project structure, you can nest semantic models under a `metrics:` folder or organize them under project sources. + + + + + +You can configure semantic models in your dbt project directory in a `YAML` file, _except_ the `dbt_project.yml` file. + +Depending on your project structure, you can nest semantic models under a `metrics:` folder or organize them under project sources. + + Semantic models have 6 components and this page explains the definitions with some examples: diff --git a/website/docs/reference/dbt_project.yml.md b/website/docs/reference/dbt_project.yml.md index 1e63beae082..0a3b76fe0a8 100644 --- a/website/docs/reference/dbt_project.yml.md +++ b/website/docs/reference/dbt_project.yml.md @@ -26,7 +26,7 @@ dbt uses YAML in a few different places. If you're new to YAML, it would be wort -The following example is a list of all available configurations in the `dbt_project.yml` file. Something to note, the following properties aren't supported in in the `dbt_project.yml` file: +Something to note, the following properties _aren't_ supported in in the `dbt_project.yml` file: - [Exposure properties](/reference/exposure-properties) - [Macro properties](/reference/macro-properties) @@ -37,7 +37,7 @@ The following example is a list of all available configurations in the `dbt_proj -The following example is a list of all available configurations in the `dbt_project.yml` file. Something to note, the following properties aren't supported in in the `dbt_project.yml` file: +Something to note, the following properties _aren't_ supported in in the `dbt_project.yml` file: - [Exposure properties](/reference/exposure-properties) - [Macro properties](/reference/macro-properties) @@ -47,6 +47,8 @@ The following example is a list of all available configurations in the `dbt_proj +The following example is a list of all available configurations in the `dbt_project.yml` file: + ```yml diff --git a/website/docs/reference/exposure-properties.md b/website/docs/reference/exposure-properties.md index 7a7b9f18790..04371d03956 100644 --- a/website/docs/reference/exposure-properties.md +++ b/website/docs/reference/exposure-properties.md @@ -11,7 +11,7 @@ description: "Read this guide to understand exposure properties in dbt." import PropsCallout from '/snippets/_config-prop-callout.md'; -Exposures are defined in `.yml` files nested under an `exposures:` key. You may define `exposures` in YAML files that also define `sources` or `models`, except in the `dbt_project.yml` files.
+Exposures are defined in `.yml` files nested under an `exposures:` key. You may define `exposures` in YAML files that also define `sources` or `models`, _except_ in the `dbt_project.yml` file.
You can name these files `whatever_you_want.yml`, and nest them arbitrarily deeply in subfolders within the `models/` directory. diff --git a/website/snippets/_config-prop-callout.md b/website/snippets/_config-prop-callout.md index a0b7e45a1de..ff49a2d297a 100644 --- a/website/snippets/_config-prop-callout.md +++ b/website/snippets/_config-prop-callout.md @@ -1 +1 @@ -This is because you can set "configs" for many resources in dbt_project.yml, while you can only set "properties" one resource at a time.

Since {props.title} are "properties", this means you cannot configure it from dbt_project.yml. Refer to Configs and properties for more info. +This is because you can set "configs" for many resources in dbt_project.yml, while you can only set "properties" one resource at a time. Since {props.title} are "properties", this means you cannot configure it from dbt_project.yml. Refer to Configs and properties for more info. From 02fb13782f920cdadab5f919022094e92a4a7cba Mon Sep 17 00:00:00 2001 From: mirnawong1 Date: Mon, 18 Sep 2023 14:18:50 +0100 Subject: [PATCH 09/25] adding jerco's great feedback --- website/docs/docs/build/semantic-models.md | 4 +- .../docs/reference/configs-and-properties.md | 13 ++-- website/docs/reference/dbt_project.yml.md | 24 +------- website/docs/reference/exposure-properties.md | 2 +- website/docs/reference/macro-properties.md | 2 +- .../docs/reference/resource-configs/docs.md | 59 +------------------ website/docs/reference/source-properties.md | 2 +- website/snippets/_config-prop-callout.md | 2 +- 8 files changed, 15 insertions(+), 93 deletions(-) diff --git a/website/docs/docs/build/semantic-models.md b/website/docs/docs/build/semantic-models.md index ca430ae5437..945282d183a 100644 --- a/website/docs/docs/build/semantic-models.md +++ b/website/docs/docs/build/semantic-models.md @@ -16,13 +16,13 @@ Each semantic model corresponds to a dbt model in your DAG. Therefore you will h -You can configure semantic models in your dbt project directory in a `YAML` file, _except_ the `dbt_project.yml` file. Depending on your project structure, you can nest semantic models under a `metrics:` folder or organize them under project sources. +You can configure semantic models in your dbt project directory in a [`properties.yml` file](/reference/configs-and-properties#where-can-i-define-properties). Depending on your project structure, you can nest semantic models under a `metrics:` folder or organize them under project sources. -You can configure semantic models in your dbt project directory in a `YAML` file, _except_ the `dbt_project.yml` file. +You can configure semantic models in your dbt project directory in a [`.yml` file](/reference/configs-and-properties#where-can-i-define-properties), however, you cannot actually define their properties within the `dbt_project.yml` file. Depending on your project structure, you can nest semantic models under a `metrics:` folder or organize them under project sources. diff --git a/website/docs/reference/configs-and-properties.md b/website/docs/reference/configs-and-properties.md index 76297f695ca..2a483296381 100644 --- a/website/docs/reference/configs-and-properties.md +++ b/website/docs/reference/configs-and-properties.md @@ -3,7 +3,7 @@ title: Configs, properties, what are they? --- Resources in your project—models, snapshots, seeds, tests, and the rest—can have a number of declared **properties**. Resources can also define **configurations**, which are a special kind of property that bring extra abilities. What's the distinction? -- Properties are declared for resources one-by-one in `.yml` files. Configs can be defined there, nested under a `config` property. They can also be set one-by-one via a `config()` macro (right within `.sql` files), and for many resources at once in `dbt_project.yml`. +- Properties are declared for resources one-by-one in `properties.yml` files. Configs can be defined there, nested under a `config` property. They can also be set one-by-one via a `config()` macro (right within `.sql` files), and for many resources at once in `dbt_project.yml`. - Because configs can be set in multiple places, they are also applied hierarchically. An individual resource might _inherit_ or _override_ configs set elsewhere. - You can select resources based on their config values using the `config:` selection method, but not the values of non-config properties @@ -46,9 +46,7 @@ Most configurations are "clobbered" when applied hierarchically. Whenever a more ## Where can I define properties? -In dbt, properties are declared in `.yml` files, in the same directory as your resources. - -You can name these files `whatever_you_want.yml` and nest them arbitrarily deeply in subfolders within each directory. +In dbt, you can use `properties.yml` files to define properties for resources. You can declare properties in `.yml` files, in the same directory as your resources. You can name these files `whatever_you_want.yml` and nest them arbitrarily in sub-folders within each directory. We highly recommend that you define properties in dedicated paths alongside the resources they're describing. @@ -56,16 +54,15 @@ We highly recommend that you define properties in dedicated paths alongside the #### schema.yml files -Previous versions of the docs referred to these as `schema.yml` files — we've moved away from that terminology since the word `schema` is used to mean other things when talking about databases, and people often thought that you _had_ to name these files `schema.yml`. +Previous versions of the docs referred to these as `schema.yml` files — we've moved away from that terminology since the word `schema` is used to mean other things when talking about databases, and people often thought that you _had_ to name these files `schema.yml`. -(Of course, you're still free to name your files `schema.yml`) +Instead, we now refer to these files as `properties.yml` files. (Of course, you're still free to name your files `schema.yml`) ::: ### Which properties are _not_ also configs? -In dbt, you can define node configs in `.yml` files, in addition to `config()` blocks and `dbt_project.yml`. However, some properties are exclusive to `.yml` files. - +In dbt, you can define node configs in `properties.yml` files, in addition to `config()` blocks and `dbt_project.yml`. However, some properties are exclusive to `.yml` files. Certain properties are special, because: diff --git a/website/docs/reference/dbt_project.yml.md b/website/docs/reference/dbt_project.yml.md index 0a3b76fe0a8..5a195dd6662 100644 --- a/website/docs/reference/dbt_project.yml.md +++ b/website/docs/reference/dbt_project.yml.md @@ -23,29 +23,7 @@ By default, dbt will look for `dbt_project.yml` in your current working director dbt uses YAML in a few different places. If you're new to YAML, it would be worth taking the time to learn how arrays, dictionaries, and strings are represented. ::: - - - -Something to note, the following properties _aren't_ supported in in the `dbt_project.yml` file: - -- [Exposure properties](/reference/exposure-properties) -- [Macro properties](/reference/macro-properties) -- [Analysis properties](/reference/analysis-properties) -- [Source properties](/reference/source-properties) - - - - - -Something to note, the following properties _aren't_ supported in in the `dbt_project.yml` file: - -- [Exposure properties](/reference/exposure-properties) -- [Macro properties](/reference/macro-properties) -- [Analysis properties](/reference/analysis-properties) -- [Semantic model configs](/docs/build/semantic-models) -- [Source properties](/reference/source-properties) - - +Something to note, you can't set up a "property" in the `dbt_project.yml` file if it's not a config (an example is [macros](/reference/macro-properties)). This applies to all types of resources. Refer to [Configs and properties](/reference/configs-and-properties) for more detail. The following example is a list of all available configurations in the `dbt_project.yml` file: diff --git a/website/docs/reference/exposure-properties.md b/website/docs/reference/exposure-properties.md index 04371d03956..ffc494f6025 100644 --- a/website/docs/reference/exposure-properties.md +++ b/website/docs/reference/exposure-properties.md @@ -11,7 +11,7 @@ description: "Read this guide to understand exposure properties in dbt." import PropsCallout from '/snippets/_config-prop-callout.md'; -Exposures are defined in `.yml` files nested under an `exposures:` key. You may define `exposures` in YAML files that also define `sources` or `models`, _except_ in the `dbt_project.yml` file.
+Exposures are defined in `.yml` files nested under an `exposures:` key. You may define `exposures` in YAML files that also define `sources` or `models`.
You can name these files `whatever_you_want.yml`, and nest them arbitrarily deeply in subfolders within the `models/` directory. diff --git a/website/docs/reference/macro-properties.md b/website/docs/reference/macro-properties.md index 348eaf6139d..685643a9aaa 100644 --- a/website/docs/reference/macro-properties.md +++ b/website/docs/reference/macro-properties.md @@ -5,7 +5,7 @@ id: macro-properties import PropsCallout from '/snippets/_config-prop-callout.md'; -Macro properties can be declared in any `.yml` file, except for the `dbt_project.yml` file. +Macro properties can be declared in any `.yml` file. You can name these files `whatever_you_want.yml` and nest them arbitrarily deep in sub-folders. diff --git a/website/docs/reference/resource-configs/docs.md b/website/docs/reference/resource-configs/docs.md index dff58be8931..a6e0f4dc9b0 100644 --- a/website/docs/reference/resource-configs/docs.md +++ b/website/docs/reference/resource-configs/docs.md @@ -20,21 +20,8 @@ default_value: {show: true} -You can use the docs property in YAML files, including the `dbt_project.yml`: - - +You can configure `docs` behavior for many resources at once by setting in `dbt_project.yml`. You can also use the `docs` config in `properties.yaml` files, to set or override documentation behaviors for specific resources: -```yml -name: "your_dbt_project_name" -version: "1.0.0" -config-version: 2 - -models: - - name: model_name - docs: - show: true | false -``` - @@ -62,19 +49,6 @@ This property is not implemented for sources. You can use the docs property in YAML files, including the `dbt_project.yml`: - - -```yml -name: "your_dbt_project_name" -version: "1.0.0" -config-version: 2 - -seeds: - - name: seed_name - docs: - show: true | false -``` - @@ -94,20 +68,6 @@ seeds: You can use the docs property in YAML files, including the `dbt_project.yml`: - - -```yml -name: "your_dbt_project_name" -version: "1.0.0" -config-version: 2 - -snapshots: - - name: snapshot_name - docs: - show: true | false -``` - - ```yml @@ -124,21 +84,8 @@ snapshots: -You can use the docs property in YAML files, including the `dbt_project.yml`: +You can use the docs property in YAML files, _except_ in `dbt_project.yml`. Refer to [Analysis properties](/reference/analysis-properties) for more info. - - -```yml -name: "your_dbt_project_name" -version: "1.0.0" -config-version: 2 - -analyses: - - name: analysis_name - docs: - show: true | false -``` - @@ -156,7 +103,7 @@ analyses: -You can use the docs property in YAML files, _except_ in `dbt_project.yml`. [Macro properties](/reference/macro-properties) _are not_ supported in the `dbt_project.yml` file. +You can use the docs property in YAML files, _except_ in `dbt_project.yml`. Refer to [Macro properties](/reference/macro-properties) for more info. diff --git a/website/docs/reference/source-properties.md b/website/docs/reference/source-properties.md index 4dee14d27f4..ead76040b05 100644 --- a/website/docs/reference/source-properties.md +++ b/website/docs/reference/source-properties.md @@ -11,7 +11,7 @@ description: "Learn how to use source properties in dbt." import PropsCallout from '/snippets/_config-prop-callout.md'; -Source properties can be declared in any `.yml` file in your `models/` directory (as defined by the [`model-paths` config](/reference/project-configs/model-paths)), except for the `dbt_project.yml` file.
+Source properties can be declared in any `.yml` file in your `models/` directory (as defined by the [`model-paths` config](/reference/project-configs/model-paths)).
You can name these files `whatever_you_want.yml`, and nest them arbitrarily deeply in subfolders within the `models/` directory: diff --git a/website/snippets/_config-prop-callout.md b/website/snippets/_config-prop-callout.md index ff49a2d297a..f21c335734a 100644 --- a/website/snippets/_config-prop-callout.md +++ b/website/snippets/_config-prop-callout.md @@ -1 +1 @@ -This is because you can set "configs" for many resources in dbt_project.yml, while you can only set "properties" one resource at a time. Since {props.title} are "properties", this means you cannot configure it from dbt_project.yml. Refer to Configs and properties for more info. +{props.title} are "special properties" in that you can't configure them in the dbt_project.yml file or using config() blocks. Refer to Configs and properties for more info. From 1872ce1d2f4edc719efb748cdc1684ad26f714d2 Mon Sep 17 00:00:00 2001 From: mirnawong1 Date: Mon, 18 Sep 2023 14:32:21 +0100 Subject: [PATCH 10/25] clarify --- website/docs/reference/configs-and-properties.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/website/docs/reference/configs-and-properties.md b/website/docs/reference/configs-and-properties.md index 2a483296381..61e401f016d 100644 --- a/website/docs/reference/configs-and-properties.md +++ b/website/docs/reference/configs-and-properties.md @@ -62,7 +62,7 @@ Instead, we now refer to these files as `properties.yml` files. (Of course, you' ### Which properties are _not_ also configs? -In dbt, you can define node configs in `properties.yml` files, in addition to `config()` blocks and `dbt_project.yml`. However, some properties are exclusive to `.yml` files. +In dbt, you can define node configs in `properties.yml` files, in addition to `config()` blocks and `dbt_project.yml`. However, some special properties can only be defined in the `.yml` file and you cannot configure them using `config()` blocks or the `dbt_project.yml` file: Certain properties are special, because: @@ -71,7 +71,7 @@ Certain properties are special, because: - They don't make sense as hierarchical configuration - They're older properties that haven't yet been redefined as configs -This means "configs" can be set for multiple resources at once in the `dbt_project.yml` file, while "properties" can only be set for one resource at a time. The following properties _cannot_ be configured from `dbt_project.yml`: +These properties are: - [`description`](/reference/resource-properties/description) - [`tests`](/reference/resource-properties/tests) From 56fbe0ae0dd3c62839c4bd23865beb26a57a8390 Mon Sep 17 00:00:00 2001 From: mirnawong1 Date: Mon, 18 Sep 2023 14:38:53 +0100 Subject: [PATCH 11/25] change yaml to `properties.yml` --- website/docs/docs/build/semantic-models.md | 2 +- website/docs/reference/exposure-properties.md | 2 +- website/docs/reference/macro-properties.md | 2 +- website/docs/reference/source-properties.md | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/website/docs/docs/build/semantic-models.md b/website/docs/docs/build/semantic-models.md index 945282d183a..af4dff406c5 100644 --- a/website/docs/docs/build/semantic-models.md +++ b/website/docs/docs/build/semantic-models.md @@ -22,7 +22,7 @@ You can configure semantic models in your dbt project directory in a [`propertie -You can configure semantic models in your dbt project directory in a [`.yml` file](/reference/configs-and-properties#where-can-i-define-properties), however, you cannot actually define their properties within the `dbt_project.yml` file. +You can configure semantic models in your dbt project directory in a [`properties.yml` file](/reference/configs-and-properties#where-can-i-define-properties), however, you cannot actually define their properties within the `dbt_project.yml` file. Depending on your project structure, you can nest semantic models under a `metrics:` folder or organize them under project sources. diff --git a/website/docs/reference/exposure-properties.md b/website/docs/reference/exposure-properties.md index ffc494f6025..0bd4cf771af 100644 --- a/website/docs/reference/exposure-properties.md +++ b/website/docs/reference/exposure-properties.md @@ -11,7 +11,7 @@ description: "Read this guide to understand exposure properties in dbt." import PropsCallout from '/snippets/_config-prop-callout.md'; -Exposures are defined in `.yml` files nested under an `exposures:` key. You may define `exposures` in YAML files that also define `sources` or `models`.
+Exposures are defined in `properties.yml` files nested under an `exposures:` key. You may define `exposures` in YAML files that also define `sources` or `models`.
You can name these files `whatever_you_want.yml`, and nest them arbitrarily deeply in subfolders within the `models/` directory. diff --git a/website/docs/reference/macro-properties.md b/website/docs/reference/macro-properties.md index 685643a9aaa..cd9ca559bac 100644 --- a/website/docs/reference/macro-properties.md +++ b/website/docs/reference/macro-properties.md @@ -5,7 +5,7 @@ id: macro-properties import PropsCallout from '/snippets/_config-prop-callout.md'; -Macro properties can be declared in any `.yml` file. +Macro properties can be declared in any `properties.yml` file. You can name these files `whatever_you_want.yml` and nest them arbitrarily deep in sub-folders. diff --git a/website/docs/reference/source-properties.md b/website/docs/reference/source-properties.md index ead76040b05..d107881967e 100644 --- a/website/docs/reference/source-properties.md +++ b/website/docs/reference/source-properties.md @@ -11,7 +11,7 @@ description: "Learn how to use source properties in dbt." import PropsCallout from '/snippets/_config-prop-callout.md'; -Source properties can be declared in any `.yml` file in your `models/` directory (as defined by the [`model-paths` config](/reference/project-configs/model-paths)).
+Source properties can be declared in any `properties.yml` file in your `models/` directory (as defined by the [`model-paths` config](/reference/project-configs/model-paths)).
You can name these files `whatever_you_want.yml`, and nest them arbitrarily deeply in subfolders within the `models/` directory: From 5ec1c05b15bea8e52181681f7c9b1882eec25181 Mon Sep 17 00:00:00 2001 From: mirnawong1 Date: Tue, 7 Nov 2023 11:27:41 +0000 Subject: [PATCH 12/25] add table --- .../docs/reference/configs-and-properties.md | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/website/docs/reference/configs-and-properties.md b/website/docs/reference/configs-and-properties.md index 61e401f016d..c427a87e795 100644 --- a/website/docs/reference/configs-and-properties.md +++ b/website/docs/reference/configs-and-properties.md @@ -11,7 +11,7 @@ A rule of thumb: properties declare things _about_ your project resources; confi For example, you can use resource **properties** to: * Describe models, snapshots, seed files, and their columns -- Assert "truths" about a model, in the form of [tests](/docs/build/tests), e.g. "this `id` column is unique" +* Assert "truths" about a model, in the form of [tests](/docs/build/tests), e.g. "this `id` column is unique" * Define pointers to existing tables that contain raw data, in the form of [sources](/docs/build/sources), and assert the expected "freshness" of this raw data * Define official downstream uses of your data models, in the form of [exposures](/docs/build/exposures) @@ -21,6 +21,21 @@ Whereas you can use **configurations** to: * Declare whether a resource should persist its descriptions as comments in the database * Apply tags and "meta" properties +### Resource, properties, and configs table + +| Resource type | Description | Supported properties | Supported configurations | Config inheritance | +|---------------|------------------|-----------------------|-----------------------------|----------------------| +| Models | Describes models and their columns | columns, tests, docs, macros | tags, materialized, persist_docs, tags, etc. | `properties.yml` -> `.yml file` -> `dbt_project.yml` | +| Snapshots | Periodic snapshots of data | tests, macros | tags, materialized, etc. | In-file `config()` block -> `.yml file` -> `dbt_project.yml` | +| Seeds | Uploaded source data for models | tests, macros | tags, persist_docs, etc. | In-file `config()` block -> `.yml file` -> `dbt_project.yml` | +| Tests | Asserts "truths" about models | description, tags, macros | In-file `config()` block -> `.yml file` -> `dbt_project.yml` | +| Sources | Pointers to tables with raw data | description, columns, tests, docs, macros | tags, persist_docs, etc. | `properties.yml` -> `.yml file` -> `dbt_project.yml` | +| Exposures | Official downstream uses of data models | description, columns, tests, docs, macros | tags, materialized, etc. | `properties.yml` -> `.yml file` -> `dbt_project.yml` | +| | | | | | +| Configurations| Extra abilities for resources | | | In-file `config()` block -> `.yml file` -> `dbt_project.yml` | +| | | | | | +| Special properties (not configs)| Special properties with unique rendering context | description, tests, docs, columns, quote, source properties, exposure properties, macro properties | | `properties.yml` | + ## Where can I define configs? Depending on the resource type, configurations can be defined: @@ -202,3 +217,4 @@ Runtime Error ``` This error occurred because a semicolon (`;`) was accidentally used instead of a colon (`:`) after the `description` field. To resolve issues like this, find the `.yml` file referenced in the error message and fix any syntax errors present in the file. There are online YAML validators that can be helpful here, but please be mindful of submitting sensitive information to third-party applications! + From ef8c3bc39c8303032571d5c4794980a7921a2579 Mon Sep 17 00:00:00 2001 From: mirnawong1 <89008547+mirnawong1@users.noreply.github.com> Date: Wed, 8 Nov 2023 14:51:17 +0000 Subject: [PATCH 13/25] Update configs-and-properties.md --- .../docs/reference/configs-and-properties.md | 19 ++----------------- 1 file changed, 2 insertions(+), 17 deletions(-) diff --git a/website/docs/reference/configs-and-properties.md b/website/docs/reference/configs-and-properties.md index c427a87e795..9a45d2bd220 100644 --- a/website/docs/reference/configs-and-properties.md +++ b/website/docs/reference/configs-and-properties.md @@ -21,21 +21,6 @@ Whereas you can use **configurations** to: * Declare whether a resource should persist its descriptions as comments in the database * Apply tags and "meta" properties -### Resource, properties, and configs table - -| Resource type | Description | Supported properties | Supported configurations | Config inheritance | -|---------------|------------------|-----------------------|-----------------------------|----------------------| -| Models | Describes models and their columns | columns, tests, docs, macros | tags, materialized, persist_docs, tags, etc. | `properties.yml` -> `.yml file` -> `dbt_project.yml` | -| Snapshots | Periodic snapshots of data | tests, macros | tags, materialized, etc. | In-file `config()` block -> `.yml file` -> `dbt_project.yml` | -| Seeds | Uploaded source data for models | tests, macros | tags, persist_docs, etc. | In-file `config()` block -> `.yml file` -> `dbt_project.yml` | -| Tests | Asserts "truths" about models | description, tags, macros | In-file `config()` block -> `.yml file` -> `dbt_project.yml` | -| Sources | Pointers to tables with raw data | description, columns, tests, docs, macros | tags, persist_docs, etc. | `properties.yml` -> `.yml file` -> `dbt_project.yml` | -| Exposures | Official downstream uses of data models | description, columns, tests, docs, macros | tags, materialized, etc. | `properties.yml` -> `.yml file` -> `dbt_project.yml` | -| | | | | | -| Configurations| Extra abilities for resources | | | In-file `config()` block -> `.yml file` -> `dbt_project.yml` | -| | | | | | -| Special properties (not configs)| Special properties with unique rendering context | description, tests, docs, columns, quote, source properties, exposure properties, macro properties | | `properties.yml` | - ## Where can I define configs? Depending on the resource type, configurations can be defined: @@ -50,11 +35,11 @@ dbt prioritizes configurations in order of specificity, from most specificity to Note - Generic tests work a little differently when it comes to specificity. See [test configs](/reference/test-configs). -Within the project file, configurations are also applied hierarchically. The most-specific config always "wins": In the project file, configurations applied to a `marketing` subdirectory will take precedence over configurations applied to the entire `jaffle_shop` project. To apply a configuration to a model, or directory of models, define the resource path as nested dictionary keys. +Within the project file, configurations are also applied hierarchically. The most specific config always "wins": In the project file, configurations applied to a `marketing` subdirectory will take precedence over configurations applied to the entire `jaffle_shop` project. To apply a configuration to a model, or directory of models, define the resource path as nested dictionary keys. ### Combining configs -Most configurations are "clobbered" when applied hierarchically. Whenever a more-specific value is available, it will completely replace the less-specific value. Note that a few configs have different merge behavior: +Most configurations are "clobbered" when applied hierarchically. Whenever a more specific value is available, it will completely replace the less specific value. Note that a few configs have different merge behavior: - [`tags`](tags) are additive. If a model has some tags configured in `dbt_project.yml`, and more tags applied in its `.sql` file, the final set of tags will include all of them. - [`meta`](/reference/resource-configs/meta) dictionaries are merged (a more specific key-value pair replaces a less specific value with the same key) - [`pre-hook` and `post-hook`](/reference/resource-configs/pre-hook-post-hook) are also additive. From 02a3cae7ca77942a2f40027cce16c25fabc36443 Mon Sep 17 00:00:00 2001 From: Doug Beatty <44704949+dbeatty10@users.noreply.github.com> Date: Fri, 10 Nov 2023 08:40:11 -0700 Subject: [PATCH 14/25] Remove trailing space --- website/docs/reference/configs-and-properties.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/docs/reference/configs-and-properties.md b/website/docs/reference/configs-and-properties.md index 9a45d2bd220..4fb9dda5aa2 100644 --- a/website/docs/reference/configs-and-properties.md +++ b/website/docs/reference/configs-and-properties.md @@ -54,7 +54,7 @@ We highly recommend that you define properties in dedicated paths alongside the #### schema.yml files -Previous versions of the docs referred to these as `schema.yml` files — we've moved away from that terminology since the word `schema` is used to mean other things when talking about databases, and people often thought that you _had_ to name these files `schema.yml`. +Previous versions of the docs referred to these as `schema.yml` files — we've moved away from that terminology since the word `schema` is used to mean other things when talking about databases, and people often thought that you _had_ to name these files `schema.yml`. Instead, we now refer to these files as `properties.yml` files. (Of course, you're still free to name your files `schema.yml`) From a1a8e7ff1f278c916aee2efd92bff6ae2b2750a2 Mon Sep 17 00:00:00 2001 From: mirnawong1 <89008547+mirnawong1@users.noreply.github.com> Date: Wed, 22 Nov 2023 07:26:03 -0500 Subject: [PATCH 15/25] Update docs.md --- website/docs/reference/resource-configs/docs.md | 15 +++------------ 1 file changed, 3 insertions(+), 12 deletions(-) diff --git a/website/docs/reference/resource-configs/docs.md b/website/docs/reference/resource-configs/docs.md index 12f95f8958e..c5e35dd64f4 100644 --- a/website/docs/reference/resource-configs/docs.md +++ b/website/docs/reference/resource-configs/docs.md @@ -20,9 +20,6 @@ default_value: {show: true} -You can configure `docs` behavior for many resources at once by setting in `dbt_project.yml`. You can also use the `docs` config in `properties.yaml` files, to set or override documentation behaviors for specific resources: - - @@ -48,9 +45,6 @@ This property is not implemented for sources. -You can use the docs property in YAML files, including the `dbt_project.yml`: - - ```yml @@ -67,8 +61,6 @@ seeds: -You can use the docs property in YAML files, including the `dbt_project.yml`: - ```yml @@ -85,9 +77,6 @@ snapshots: -You can use the docs property in YAML files, _except_ in `dbt_project.yml`. Refer to [Analysis properties](/reference/analysis-properties) for more info. - - ```yml @@ -104,7 +93,9 @@ analyses: -You can use the docs property in YAML files, _except_ in `dbt_project.yml`. Refer to [Macro properties](/reference/macro-properties) for more info. + From c9ce5465bd5464326830ad61fbd13beae48b3c53 Mon Sep 17 00:00:00 2001 From: mirnawong1 Date: Fri, 15 Dec 2023 15:24:18 -0500 Subject: [PATCH 16/25] update behavior adn code --- website/src/components/detailsToggle/index.js | 36 +++++++++---------- 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/website/src/components/detailsToggle/index.js b/website/src/components/detailsToggle/index.js index 90464328f8b..ba53192e54b 100644 --- a/website/src/components/detailsToggle/index.js +++ b/website/src/components/detailsToggle/index.js @@ -7,29 +7,29 @@ function detailsToggle({ children, alt_header = null }) { const [hoverTimeout, setHoverTimeout] = useState(null); const handleToggleClick = () => { - setOn(false); - setHoverActive(isOn); // Toggle hover activation based on current state - }; + setHoverActive(true); // Disable hover when clicked + setOn(current => !current); // Toggle the current state +}; - const handleMouseEnter = () => { - if (!hoverActive) return; // Ignore hover if disabled - const timeout = setTimeout(() => { - setOn(true); - }, 500); // 500ms delay - setHoverTimeout(timeout); - }; +const handleMouseEnter = () => { + if (isOn) return; // Ignore hover if already open + setHoverActive(true); // Enable hover + const timeout = setTimeout(() => { + if (hoverActive) setOn(true); + }, 500); + setHoverTimeout(timeout); +}; - const handleMouseLeave = () => { - if (hoverActive && !isOn) { +const handleMouseLeave = () => { + if (!isOn) { clearTimeout(hoverTimeout); setOn(false); - // isOn (false); can't be used here but setOn triggers a re-render - } - }; + } +}; - useEffect(() => { - return () => clearTimeout(hoverTimeout); - }, [hoverTimeout]); +useEffect(() => { + return () => clearTimeout(hoverTimeout); +}, [hoverTimeout]); return (
From 8c7913dee94d5ee88ad589de25b698b1d6780d86 Mon Sep 17 00:00:00 2001 From: mirnawong1 <89008547+mirnawong1@users.noreply.github.com> Date: Fri, 15 Dec 2023 15:38:53 -0500 Subject: [PATCH 17/25] Update _sl-faqs.md --- website/snippets/_sl-faqs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/snippets/_sl-faqs.md b/website/snippets/_sl-faqs.md index 092929e1066..75583bfa2f6 100644 --- a/website/snippets/_sl-faqs.md +++ b/website/snippets/_sl-faqs.md @@ -44,7 +44,7 @@ If you're using the legacy Semantic Layer, we highly recommend you [upgrade your - + User data passes through the Semantic Layer on its way back from the warehouse. dbt Labs ensures security by authenticating through the customer's data warehouse. Currently, we don't cache data for the long term, but it might temporarily stay in the system for up to 10 minutes, usually less. In the future, we'll introduce a caching feature that allows us to cache data on our infrastructure for up to 24 hours. From 05523d4c34078676212d6186f11aab10f86b7113 Mon Sep 17 00:00:00 2001 From: Doug Beatty <44704949+dbeatty10@users.noreply.github.com> Date: Fri, 15 Dec 2023 15:49:08 -0700 Subject: [PATCH 18/25] Only display intro (rather than entire article) during listing of blog posts --- .../blog/2023-05-02-modeling-ragged-time-varying-hierarchies.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/website/blog/2023-05-02-modeling-ragged-time-varying-hierarchies.md b/website/blog/2023-05-02-modeling-ragged-time-varying-hierarchies.md index d436df2628a..f719bdb40cb 100644 --- a/website/blog/2023-05-02-modeling-ragged-time-varying-hierarchies.md +++ b/website/blog/2023-05-02-modeling-ragged-time-varying-hierarchies.md @@ -16,6 +16,8 @@ This article covers an approach to handling time-varying ragged hierarchies in a To help visualize this data, we're going to pretend we are a company that manufactures and rents out eBikes in a ride share application. When we build a bike, we keep track of the serial numbers of the components that make up the bike. Any time something breaks and needs to be replaced, we track the old parts that were removed and the new parts that were installed. We also precisely track the mileage accumulated on each of our bikes. Our primary analytical goal is to be able to report on the expected lifetime of each component, so we can prioritize improving that component and reduce costly maintenance. + + ## Data model Obviously, a real bike could have a hundred or more separate components. To keep things simple for this article, let's just consider the bike, the frame, a wheel, the wheel rim, tire, and tube. Our component hierarchy looks like: From 7ad36fdb848d35009f57c1939b24032e9f67861a Mon Sep 17 00:00:00 2001 From: Doug Beatty <44704949+dbeatty10@users.noreply.github.com> Date: Sun, 17 Dec 2023 11:15:58 -0700 Subject: [PATCH 19/25] Update dbt_project.yml.md Remove duplicated content --- website/docs/reference/dbt_project.yml.md | 22 ---------------------- 1 file changed, 22 deletions(-) diff --git a/website/docs/reference/dbt_project.yml.md b/website/docs/reference/dbt_project.yml.md index d130b5cf1f5..9252d13681f 100644 --- a/website/docs/reference/dbt_project.yml.md +++ b/website/docs/reference/dbt_project.yml.md @@ -25,28 +25,6 @@ Something to note, you can't set up a "property" in the `dbt_project.yml` file i The following example is a list of all available configurations in the `dbt_project.yml` file: - - - -By default, dbt will look for `dbt_project.yml` in your current working directory and its parents, but you can set a different directory using the `--project-dir` flag. - - - - - -By default, dbt will look for `dbt_project.yml` in your current working directory and its parents, but you can set a different directory using the `--project-dir` flag or the `DBT_PROJECT_DIR` environment variable. - -Starting from dbt v1.5 and higher, you can specify your dbt Cloud project ID in the `dbt_project.yml` file using `project-id` under the `dbt-cloud` config. To find your project ID, check your dbt Cloud project URL, such as `https://cloud.getdbt.com/11/projects/123456`, where the project ID is `123456`. - - - -The following is a list of all available configurations in the `dbt_project.yml` file. - -:::info YAML syntax -dbt uses YAML in a few different places. If you're new to YAML, it would be worth taking the time to learn how arrays, dictionaries and strings are represented. -::: - - From c26bc3965a4bfb0c72eb8f128ddc21a28cded1b5 Mon Sep 17 00:00:00 2001 From: Doug Beatty <44704949+dbeatty10@users.noreply.github.com> Date: Sun, 17 Dec 2023 11:27:13 -0700 Subject: [PATCH 20/25] Remove extra newline --- website/docs/reference/dbt_project.yml.md | 1 - 1 file changed, 1 deletion(-) diff --git a/website/docs/reference/dbt_project.yml.md b/website/docs/reference/dbt_project.yml.md index 9252d13681f..a5ad601f78b 100644 --- a/website/docs/reference/dbt_project.yml.md +++ b/website/docs/reference/dbt_project.yml.md @@ -16,7 +16,6 @@ Starting from dbt v1.5 and higher, you can specify your dbt Cloud project ID in :::info YAML syntax - dbt uses YAML in a few different places. If you're new to YAML, it would be worth taking the time to learn how arrays, dictionaries, and strings are represented. ::: From eca769c4c039407207a33bf9f554e438489fbe4f Mon Sep 17 00:00:00 2001 From: mirnawong1 <89008547+mirnawong1@users.noreply.github.com> Date: Mon, 18 Dec 2023 06:01:18 -0500 Subject: [PATCH 21/25] link to clone in ci job best practices this pr adds a link to the clone in a ci job best practices guide as a callout per slack request https://dbt-labs.slack.com/archives/C02NCQ9483C/p1702655617781059 --- website/blog/2023-10-31-to-defer-or-to-clone.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/website/blog/2023-10-31-to-defer-or-to-clone.md b/website/blog/2023-10-31-to-defer-or-to-clone.md index a39fc3ac0b7..2d72eee3297 100755 --- a/website/blog/2023-10-31-to-defer-or-to-clone.md +++ b/website/blog/2023-10-31-to-defer-or-to-clone.md @@ -91,6 +91,10 @@ Using the cheat sheet above, let’s explore a few common scenarios and explore 2. **[Slim CI](https://discourse.getdbt.com/t/how-we-sped-up-our-ci-runs-by-10x-using-slim-ci/2603)** + :::tip Use `dbt clone` in CI jobs + Learn how to [use `dbt clone` in CI jobs](/best-practices/clone-incremental-models) to efficiently test modified incremental models, simulating post-merge behavior while avoiding full-refresh costs. + ::: + In this scenario, we want to: 1. Refer to production models wherever possible to speed up continuous integration (CI) runs 2. Only run and test models in the CI staging environment that have changed from the production environment @@ -98,7 +102,7 @@ Using the cheat sheet above, let’s explore a few common scenarios and explore Therefore, we should use **defer** in this scenario -3. **[Blue/Green Deployments](https://discourse.getdbt.com/t/performing-a-blue-green-deploy-of-your-dbt-project-on-snowflake/1349)** +4. **[Blue/Green Deployments](https://discourse.getdbt.com/t/performing-a-blue-green-deploy-of-your-dbt-project-on-snowflake/1349)** In this scenario, we want to: 1. Ensure that all tests are always passing on the production dataset, even if that dataset is slightly stale From c1a6d9c9e3e5e50595deb09e8060044e290a1b1d Mon Sep 17 00:00:00 2001 From: mirnawong1 <89008547+mirnawong1@users.noreply.github.com> Date: Mon, 18 Dec 2023 06:02:12 -0500 Subject: [PATCH 22/25] Update website/blog/2023-10-31-to-defer-or-to-clone.md --- website/blog/2023-10-31-to-defer-or-to-clone.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/blog/2023-10-31-to-defer-or-to-clone.md b/website/blog/2023-10-31-to-defer-or-to-clone.md index 2d72eee3297..4777022e5cd 100755 --- a/website/blog/2023-10-31-to-defer-or-to-clone.md +++ b/website/blog/2023-10-31-to-defer-or-to-clone.md @@ -102,7 +102,7 @@ Using the cheat sheet above, let’s explore a few common scenarios and explore Therefore, we should use **defer** in this scenario -4. **[Blue/Green Deployments](https://discourse.getdbt.com/t/performing-a-blue-green-deploy-of-your-dbt-project-on-snowflake/1349)** +3. **[Blue/Green Deployments](https://discourse.getdbt.com/t/performing-a-blue-green-deploy-of-your-dbt-project-on-snowflake/1349)** In this scenario, we want to: 1. Ensure that all tests are always passing on the production dataset, even if that dataset is slightly stale From 301c8a9e04d559bacf80e0e7591d6e094064267f Mon Sep 17 00:00:00 2001 From: mirnawong1 <89008547+mirnawong1@users.noreply.github.com> Date: Mon, 18 Dec 2023 06:03:30 -0500 Subject: [PATCH 23/25] Update website/blog/2023-10-31-to-defer-or-to-clone.md --- website/blog/2023-10-31-to-defer-or-to-clone.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/blog/2023-10-31-to-defer-or-to-clone.md b/website/blog/2023-10-31-to-defer-or-to-clone.md index 4777022e5cd..53b40f244dd 100755 --- a/website/blog/2023-10-31-to-defer-or-to-clone.md +++ b/website/blog/2023-10-31-to-defer-or-to-clone.md @@ -91,7 +91,7 @@ Using the cheat sheet above, let’s explore a few common scenarios and explore 2. **[Slim CI](https://discourse.getdbt.com/t/how-we-sped-up-our-ci-runs-by-10x-using-slim-ci/2603)** - :::tip Use `dbt clone` in CI jobs + :::tip Use `dbt clone` in CI jobs to test incremental models Learn how to [use `dbt clone` in CI jobs](/best-practices/clone-incremental-models) to efficiently test modified incremental models, simulating post-merge behavior while avoiding full-refresh costs. ::: From 7d81a535342e01891f2d5837ded9975ef338e639 Mon Sep 17 00:00:00 2001 From: mirnawong1 <89008547+mirnawong1@users.noreply.github.com> Date: Mon, 18 Dec 2023 06:13:53 -0500 Subject: [PATCH 24/25] Update 2023-10-31-to-defer-or-to-clone.md --- website/blog/2023-10-31-to-defer-or-to-clone.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/website/blog/2023-10-31-to-defer-or-to-clone.md b/website/blog/2023-10-31-to-defer-or-to-clone.md index 53b40f244dd..9454ad11281 100755 --- a/website/blog/2023-10-31-to-defer-or-to-clone.md +++ b/website/blog/2023-10-31-to-defer-or-to-clone.md @@ -91,18 +91,18 @@ Using the cheat sheet above, let’s explore a few common scenarios and explore 2. **[Slim CI](https://discourse.getdbt.com/t/how-we-sped-up-our-ci-runs-by-10x-using-slim-ci/2603)** - :::tip Use `dbt clone` in CI jobs to test incremental models - Learn how to [use `dbt clone` in CI jobs](/best-practices/clone-incremental-models) to efficiently test modified incremental models, simulating post-merge behavior while avoiding full-refresh costs. - ::: - In this scenario, we want to: 1. Refer to production models wherever possible to speed up continuous integration (CI) runs 2. Only run and test models in the CI staging environment that have changed from the production environment 3. Reference models from different environments – prod for unchanged models, and staging for modified models Therefore, we should use **defer** in this scenario + + :::tip Use `dbt clone` in CI jobs to test incremental models + Learn how to [use `dbt clone` in CI jobs](/best-practices/clone-incremental-models) to efficiently test modified incremental models, simulating post-merge behavior while avoiding full-refresh costs. + ::: -3. **[Blue/Green Deployments](https://discourse.getdbt.com/t/performing-a-blue-green-deploy-of-your-dbt-project-on-snowflake/1349)** +4. **[Blue/Green Deployments](https://discourse.getdbt.com/t/performing-a-blue-green-deploy-of-your-dbt-project-on-snowflake/1349)** In this scenario, we want to: 1. Ensure that all tests are always passing on the production dataset, even if that dataset is slightly stale From 25c2af99bde23bfe607004b9eb29188d67015b8b Mon Sep 17 00:00:00 2001 From: mirnawong1 <89008547+mirnawong1@users.noreply.github.com> Date: Mon, 18 Dec 2023 06:48:37 -0500 Subject: [PATCH 25/25] Update 2023-10-31-to-defer-or-to-clone.md --- website/blog/2023-10-31-to-defer-or-to-clone.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/website/blog/2023-10-31-to-defer-or-to-clone.md b/website/blog/2023-10-31-to-defer-or-to-clone.md index 9454ad11281..00aa8c7f7e5 100755 --- a/website/blog/2023-10-31-to-defer-or-to-clone.md +++ b/website/blog/2023-10-31-to-defer-or-to-clone.md @@ -87,7 +87,7 @@ Using the cheat sheet above, let’s explore a few common scenarios and explore 1. Make a copy of our production dataset available in our downstream BI tool 2. To safely iterate on this copy without breaking production datasets - Therefore, we should use **clone** in this scenario + Therefore, we should use **clone** in this scenario. 2. **[Slim CI](https://discourse.getdbt.com/t/how-we-sped-up-our-ci-runs-by-10x-using-slim-ci/2603)** @@ -96,13 +96,13 @@ Using the cheat sheet above, let’s explore a few common scenarios and explore 2. Only run and test models in the CI staging environment that have changed from the production environment 3. Reference models from different environments – prod for unchanged models, and staging for modified models - Therefore, we should use **defer** in this scenario + Therefore, we should use **defer** in this scenario. - :::tip Use `dbt clone` in CI jobs to test incremental models - Learn how to [use `dbt clone` in CI jobs](/best-practices/clone-incremental-models) to efficiently test modified incremental models, simulating post-merge behavior while avoiding full-refresh costs. - ::: +:::tip Use `dbt clone` in CI jobs to test incremental models +Learn how to [use `dbt clone` in CI jobs](/best-practices/clone-incremental-models) to efficiently test modified incremental models, simulating post-merge behavior while avoiding full-refresh costs. +::: -4. **[Blue/Green Deployments](https://discourse.getdbt.com/t/performing-a-blue-green-deploy-of-your-dbt-project-on-snowflake/1349)** +3. **[Blue/Green Deployments](https://discourse.getdbt.com/t/performing-a-blue-green-deploy-of-your-dbt-project-on-snowflake/1349)** In this scenario, we want to: 1. Ensure that all tests are always passing on the production dataset, even if that dataset is slightly stale