From 2a7825adbeee427fd14cf15abec685c39b578625 Mon Sep 17 00:00:00 2001 From: Amy Chen <46451573+amychen1776@users.noreply.github.com> Date: Wed, 8 Jan 2025 19:46:45 -0500 Subject: [PATCH 01/28] Update snowflake-configs.md --- .../docs/reference/resource-configs/snowflake-configs.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/website/docs/reference/resource-configs/snowflake-configs.md b/website/docs/reference/resource-configs/snowflake-configs.md index 9d84e892236..31c399219e4 100644 --- a/website/docs/reference/resource-configs/snowflake-configs.md +++ b/website/docs/reference/resource-configs/snowflake-configs.md @@ -337,6 +337,13 @@ For dbt limitations, these dbt features are not supported: - [Model contracts](/docs/collaborate/govern/model-contracts) - [Copy grants configuration](/reference/resource-configs/snowflake-configs#copying-grants) +### Troubleshooting Dynamic Tables +- If your dynamic table model is unable to rerun after the initial execution and fails with this error message: + ```sql + SnowflakeDynamicTableConfig.__init__() missing 6 required positional arguments: 'name', 'schema_name', 'database_name', 'query', 'target_lag', and 'snowflake_warehouse' + ``` + Check to ensure that `QUOTED_IDENTIFIERS_IGNORE_CASE` on your account is set to FALSE. + ## Temporary tables Incremental table merges for Snowflake prefer to utilize a `view` rather than a `temporary table`. The reasoning is to avoid the database write step that a temporary table would initiate and save compile time. From 7fa317d1d078066f853cdc4153038e1640b6c119 Mon Sep 17 00:00:00 2001 From: Matt Shaver <60105315+matthewshaver@users.noreply.github.com> Date: Wed, 8 Jan 2025 19:49:55 -0500 Subject: [PATCH 02/28] Apply suggestions from code review --- website/docs/reference/resource-configs/snowflake-configs.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/website/docs/reference/resource-configs/snowflake-configs.md b/website/docs/reference/resource-configs/snowflake-configs.md index 31c399219e4..a9038c5b266 100644 --- a/website/docs/reference/resource-configs/snowflake-configs.md +++ b/website/docs/reference/resource-configs/snowflake-configs.md @@ -338,11 +338,11 @@ For dbt limitations, these dbt features are not supported: - [Copy grants configuration](/reference/resource-configs/snowflake-configs#copying-grants) ### Troubleshooting Dynamic Tables -- If your dynamic table model is unable to rerun after the initial execution and fails with this error message: +- If your dynamic table model fails to rerun with the following error message after the initial execution: ```sql SnowflakeDynamicTableConfig.__init__() missing 6 required positional arguments: 'name', 'schema_name', 'database_name', 'query', 'target_lag', and 'snowflake_warehouse' ``` - Check to ensure that `QUOTED_IDENTIFIERS_IGNORE_CASE` on your account is set to FALSE. + Ensure that `QUOTED_IDENTIFIERS_IGNORE_CASE` on your account is set to `FALSE`. ## Temporary tables From 3063f0c4cfba48ffd58d1c56838a6d2abe81c45a Mon Sep 17 00:00:00 2001 From: Matt Shaver <60105315+matthewshaver@users.noreply.github.com> Date: Wed, 8 Jan 2025 19:50:25 -0500 Subject: [PATCH 03/28] Update website/docs/reference/resource-configs/snowflake-configs.md --- website/docs/reference/resource-configs/snowflake-configs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/docs/reference/resource-configs/snowflake-configs.md b/website/docs/reference/resource-configs/snowflake-configs.md index a9038c5b266..b21036d14c7 100644 --- a/website/docs/reference/resource-configs/snowflake-configs.md +++ b/website/docs/reference/resource-configs/snowflake-configs.md @@ -337,7 +337,7 @@ For dbt limitations, these dbt features are not supported: - [Model contracts](/docs/collaborate/govern/model-contracts) - [Copy grants configuration](/reference/resource-configs/snowflake-configs#copying-grants) -### Troubleshooting Dynamic Tables +### Troubleshooting dynamic tables - If your dynamic table model fails to rerun with the following error message after the initial execution: ```sql SnowflakeDynamicTableConfig.__init__() missing 6 required positional arguments: 'name', 'schema_name', 'database_name', 'query', 'target_lag', and 'snowflake_warehouse' From 7f7fd9c6db7adba3906a3e2bf3650e9cc64a6a4a Mon Sep 17 00:00:00 2001 From: Matt Shaver <60105315+matthewshaver@users.noreply.github.com> Date: Wed, 8 Jan 2025 19:52:32 -0500 Subject: [PATCH 04/28] Update snowflake-configs.md Removing bullet until there are more items --- .../reference/resource-configs/snowflake-configs.md | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/website/docs/reference/resource-configs/snowflake-configs.md b/website/docs/reference/resource-configs/snowflake-configs.md index b21036d14c7..30275450793 100644 --- a/website/docs/reference/resource-configs/snowflake-configs.md +++ b/website/docs/reference/resource-configs/snowflake-configs.md @@ -338,11 +338,13 @@ For dbt limitations, these dbt features are not supported: - [Copy grants configuration](/reference/resource-configs/snowflake-configs#copying-grants) ### Troubleshooting dynamic tables -- If your dynamic table model fails to rerun with the following error message after the initial execution: - ```sql - SnowflakeDynamicTableConfig.__init__() missing 6 required positional arguments: 'name', 'schema_name', 'database_name', 'query', 'target_lag', and 'snowflake_warehouse' - ``` - Ensure that `QUOTED_IDENTIFIERS_IGNORE_CASE` on your account is set to `FALSE`. + +If your dynamic table model fails to rerun with the following error message after the initial execution: + +```sql +SnowflakeDynamicTableConfig.__init__() missing 6 required positional arguments: 'name', 'schema_name', 'database_name', 'query', 'target_lag', and 'snowflake_warehouse' +``` +Ensure that `QUOTED_IDENTIFIERS_IGNORE_CASE` on your account is set to `FALSE`. ## Temporary tables From df33b0ed60da4f88526981d9074346bb4e735b7d Mon Sep 17 00:00:00 2001 From: mirnawong1 Date: Fri, 10 Jan 2025 12:37:58 +0000 Subject: [PATCH 05/28] add model example --- .../docs/reference/resource-configs/tags.md | 76 ++++++++++++++++--- 1 file changed, 67 insertions(+), 9 deletions(-) diff --git a/website/docs/reference/resource-configs/tags.md b/website/docs/reference/resource-configs/tags.md index 505a33a00f7..aa55ba89efe 100644 --- a/website/docs/reference/resource-configs/tags.md +++ b/website/docs/reference/resource-configs/tags.md @@ -93,6 +93,21 @@ resource_type: ``` + +For example, to apply tags to a model in your `models/` directory, you would add the following using the `config` property: + + + +```yaml +models: + - name: my_model + description: A model description + config: + tags: ['example_tag'] +``` + + + @@ -126,10 +141,22 @@ You can use the [`+` operator](/reference/node-selection/graph-operators#the-plu - `dbt run --select +model_name+` — Run a model, its upstream dependencies, and its downstream dependencies. - `dbt run --select tag:my_tag+ --exclude tag:exclude_tag` — Run model tagged with `my_tag` and their downstream dependencies, and exclude models tagged with `exclude_tag`, regardless of their dependencies. + +:::tip Usage notes about tags + +- Tags are additive across project hierarchy. +- Some resource types (like sources, exposures) require tags at the top level. + +Refer to [usage notes](#usage-notes) for more information. +::: + ## Examples + +The following examples show how to apply tags to resources in your project. You can configure tags in the `dbt_project.yml`, `schema.yml`, or SQL files. + ### Use tags to run parts of your project -Apply tags in your `dbt_project.yml` as a single value or a string: +Apply tags in your `dbt_project.yml` as a single value or a string. In the following example, one of the models, the `jaffle_shop` model, is tagged with `contains_pii`. @@ -153,16 +180,52 @@ models: - "published" ``` + + + +### Apply tags to models + +You can also apply tags to individual resources, like models, using in the `dbt_project.yml`, `schema.yml`, or SQL files. + +To apply tags to a model in your `dbt_project.yml` file, you would add the following: + + + +```yaml +models: + jaffle_shop: + +tags: finance # jaffle_shop model is tagged with 'finance'. +``` -You can also apply tags to individual resources using a config block: +To apply tags to a model in your `models/` directory YAML file, you would add the following using the `config` property: + + + +```yaml +models: + - name: stg_customers + description: Customer data with basic cleaning and transformation applied, one row per customer. + config: + tags: ['santi'] # stg_customers.yml model is tagged with 'santi'. + columns: + - name: customer_id + description: The unique key for each customer. + data_tests: + - not_null + - unique +``` + + + +To apply tags to a model in your SQL file, you would add the following: ```sql {{ config( - tags=["finance"] + tags=["finance"] # stg_payments.sql model is tagged with 'finance'. ) }} select ... @@ -211,14 +274,10 @@ seeds: -:::tip Upgrade to dbt Core 1.9 - -Applying tags to saved queries is only available in dbt Core versions 1.9 and later. -::: + - This following example shows how to apply a tag to a saved query in the `dbt_project.yml` file. The saved query is then tagged with `order_metrics`. @@ -263,7 +322,6 @@ Run resources with multiple tags using the following commands: # Run all resources tagged "order_metrics" and "hourly" dbt build --select tag:order_metrics tag:hourly ``` - ## Usage notes From ff2744b94672e68f59aec02953c2997e1423d222 Mon Sep 17 00:00:00 2001 From: Mirna Wong <89008547+mirnawong1@users.noreply.github.com> Date: Fri, 10 Jan 2025 12:44:50 +0000 Subject: [PATCH 06/28] Update website/docs/reference/resource-configs/tags.md --- website/docs/reference/resource-configs/tags.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/docs/reference/resource-configs/tags.md b/website/docs/reference/resource-configs/tags.md index aa55ba89efe..cda0bec58b1 100644 --- a/website/docs/reference/resource-configs/tags.md +++ b/website/docs/reference/resource-configs/tags.md @@ -185,7 +185,7 @@ models: ### Apply tags to models -You can also apply tags to individual resources, like models, using in the `dbt_project.yml`, `schema.yml`, or SQL files. +This section shares how to apply tags to models in the `dbt_project.yml`, `schema.yml`, or SQL files, however you can also apply tags to individual resources. To apply tags to a model in your `dbt_project.yml` file, you would add the following: From 1daf44d11456b789343e6547b78549843b2285e6 Mon Sep 17 00:00:00 2001 From: mirnawong1 Date: Fri, 10 Jan 2025 17:03:00 +0000 Subject: [PATCH 07/28] add considerations --- .../reference/resource-configs/event-time.md | 27 ++++++++++++------- 1 file changed, 17 insertions(+), 10 deletions(-) diff --git a/website/docs/reference/resource-configs/event-time.md b/website/docs/reference/resource-configs/event-time.md index e746b7658ba..bff35b49711 100644 --- a/website/docs/reference/resource-configs/event-time.md +++ b/website/docs/reference/resource-configs/event-time.md @@ -21,7 +21,6 @@ models: ``` - ```yml @@ -139,20 +138,28 @@ sources: ## Definition -Set the `event_time` to the name of the field that represents the timestamp of the event -- "at what time did the row occur" -- as opposed to an event ingestion date. You can configure `event_time` for a [model](/docs/build/models), [seed](/docs/build/seeds), or [source](/docs/build/sources) in your `dbt_project.yml` file, property YAML file, or config block. +You can configure `event_time` for a [model](/docs/build/models), [seed](/docs/build/seeds), or [source](/docs/build/sources) in your `dbt_project.yml` file, property YAML file, or config block. + +`event_time` is required for the [incremental microbatch](/docs/build/incremental-microbatch) strategy and highly recommended for [Advanced CI's compare changes](/docs/deploy/dvanced-ci#optimizing-comparisons) in CI/CD workflows, where it ensures the same time-slice of data is correctly compared between your CI and production environments. + +### Best practices + +Set the `event_time` to the name of the field that represents the actual timestamp of the event (like `account_created_at`). The timestamp of the event should represent "at what time did the row occur" rather than an event ingestion date. -Here are some examples of good and bad `event_time` columns: +However, if an ingestion date (like `loaded_at`, `ingested_at`, or `last_updated_at`) are the only timestamps you use, you can set `event_time` to these fields. Here are some considerations to keep in mind if you do this: -- ✅ Good: - - `account_created_at` — This represents the specific time when an account was created, making it a fixed event in time. - - `session_began_at` — This captures the exact timestamp when a user session started, which won’t change and directly ties to the event. +- Using `last_updated_at` or `loaded_at` — May result in duplicate entries in the resulting table in the data warehouse over multiple runs. Setting an appropriate [lookback](/reference/resource-configs/lookback) value can reduce duplicates but it can't fully eliminate them since some updates outside the lookback window won't be processed. +- Using `ingested_at` — Represents when data was ingested, (not when the event occurred). This is less semantically meaningful for the underlying data and may require more filtering during query time. -- ❌ Bad: +Here are some examples of recommended and not recommended `event_time` columns: - - `_fivetran_synced` — This isn't the time that the event happened, it's the time that the event was ingested. - - `last_updated_at` — This isn't a good use case as this will keep changing over time. -`event_time` is required for [Incremental microbatch](/docs/build/incremental-microbatch) and highly recommended for [Advanced CI's compare changes](/docs/deploy/advanced-ci#optimizing-comparisons) in CI/CD workflows, where it ensures the same time-slice of data is correctly compared between your CI and production environments. +|
Status
| Column name | Description | +|--------------------|---------------------|----------------------| +| ✅ Recommended | `account_created_at` | Represents the specific time when an account was created, making it a fixed event in time. | +| ✅ Recommended | `session_began_at` | Captures the exact timestamp when a user session started, which won’t change and directly ties to the event. | +| ❌ Not recommended | `_fivetran_synced` | This represents the time the event was ingested, not when it happened. | +| ❌ Not recommended | `last_updated_at` | Changes over time and is not tied to the event itself. If used, note the considerations regarding duplicates. | ## Examples From be80d15d06512f99b01bffc0488ad38f5071adf5 Mon Sep 17 00:00:00 2001 From: mirnawong1 Date: Fri, 10 Jan 2025 17:08:11 +0000 Subject: [PATCH 08/28] fix link --- website/docs/reference/resource-configs/event-time.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/docs/reference/resource-configs/event-time.md b/website/docs/reference/resource-configs/event-time.md index bff35b49711..44b6dbd3b16 100644 --- a/website/docs/reference/resource-configs/event-time.md +++ b/website/docs/reference/resource-configs/event-time.md @@ -140,7 +140,7 @@ sources: You can configure `event_time` for a [model](/docs/build/models), [seed](/docs/build/seeds), or [source](/docs/build/sources) in your `dbt_project.yml` file, property YAML file, or config block. -`event_time` is required for the [incremental microbatch](/docs/build/incremental-microbatch) strategy and highly recommended for [Advanced CI's compare changes](/docs/deploy/dvanced-ci#optimizing-comparisons) in CI/CD workflows, where it ensures the same time-slice of data is correctly compared between your CI and production environments. +`event_time` is required for the [incremental microbatch](/docs/build/incremental-microbatch) strategy and highly recommended for [Advanced CI's compare changes](/docs/deploy/advanced-ci#optimizing-comparisons) in CI/CD workflows, where it ensures the same time-slice of data is correctly compared between your CI and production environments. ### Best practices From 7eaebc9ec351bd61ba21cc61a5f88e26dae73385 Mon Sep 17 00:00:00 2001 From: Mirna Wong <89008547+mirnawong1@users.noreply.github.com> Date: Fri, 10 Jan 2025 17:15:00 +0000 Subject: [PATCH 09/28] Update event-time.md --- website/docs/reference/resource-configs/event-time.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/docs/reference/resource-configs/event-time.md b/website/docs/reference/resource-configs/event-time.md index 44b6dbd3b16..2dfd17399ad 100644 --- a/website/docs/reference/resource-configs/event-time.md +++ b/website/docs/reference/resource-configs/event-time.md @@ -159,7 +159,7 @@ Here are some examples of recommended and not recommended `event_time` columns: | ✅ Recommended | `account_created_at` | Represents the specific time when an account was created, making it a fixed event in time. | | ✅ Recommended | `session_began_at` | Captures the exact timestamp when a user session started, which won’t change and directly ties to the event. | | ❌ Not recommended | `_fivetran_synced` | This represents the time the event was ingested, not when it happened. | -| ❌ Not recommended | `last_updated_at` | Changes over time and is not tied to the event itself. If used, note the considerations regarding duplicates. | +| ❌ Not recommended | `last_updated_at` | Changes over time and isn't tied to the event itself. If used, note the considerations mentioned earlier in [best practices](#best-practices). | ## Examples From cf1de669c0f73b07393147592bb47c1db080ad84 Mon Sep 17 00:00:00 2001 From: Emily Rockman Date: Sat, 11 Jan 2025 09:28:10 -0600 Subject: [PATCH 10/28] Add changelogs for 1/2025 compatible update --- .../compatible-track-changelog.md | 44 +++++++++++++++++++ 1 file changed, 44 insertions(+) diff --git a/website/docs/docs/dbt-versions/compatible-track-changelog.md b/website/docs/docs/dbt-versions/compatible-track-changelog.md index a8243e2ceff..fd16d5076f4 100644 --- a/website/docs/docs/dbt-versions/compatible-track-changelog.md +++ b/website/docs/docs/dbt-versions/compatible-track-changelog.md @@ -18,6 +18,50 @@ Starting in January 2025, each monthly "Extended" release will match the previou For more information, see [release tracks](/docs/dbt-versions/cloud-release-tracks). +## January 2025 + +Release date: January 14, 2025 + +This release includes functionality from the following versions of dbt Core OSS: +``` +dbt-core==1.9.1 + +# shared interfaces +dbt-adapters==1.13.1 +dbt-common==1.14.0 +dbt-semantic-interfaces==0.7.4 + +# adapters +dbt-athena==1.9.0 +dbt-bigquery==1.9.1 +dbt-databricks==1.9.1 +dbt-fabric==1.9.0 +dbt-postgres==1.9.0 +dbt-redshift==1.9.0 +dbt-snowflake==1.9.0 +dbt-spark==1.9.0 +dbt-synapse==1.8.2 +dbt-teradata==1.9.0 +dbt-trino==1.9.0 +``` + +Changelogs: +- [dbt-core 1.9.1](https://github.com/dbt-labs/dbt-core/blob/1.9.latest/CHANGELOG.md#dbt-core-191---december-16-2024) +- [dbt-adapters 1.13.1](https://github.com/dbt-labs/dbt-adapters/blob/main/CHANGELOG.md#dbt-adapters-1131---january-10-2025) +- [dbt-common 1.14.0](https://github.com/dbt-labs/dbt-common/blob/main/CHANGELOG.md) +- [dbt-bigquery 1.9.1](https://github.com/dbt-labs/dbt-bigquery/blob/1.9.latest/CHANGELOG.md#dbt-bigquery-191---january-10-2025) +- [dbt-databricks 1.9.1](https://github.com/databricks/dbt-databricks/blob/main/CHANGELOG.md#dbt-databricks-191-december-16-2024) +- [dbt-fabric 1.9.0](https://github.com/microsoft/dbt-fabric/releases/tag/v1.9.0) +- [dbt-postgres 1.9.0](https://github.com/dbt-labs/dbt-postgres/blob/main/CHANGELOG.md#dbt-postgres-190---december-09-2024) +- [dbt-redshift 1.9.0](https://github.com/dbt-labs/dbt-redshift/blob/1.9.latest/CHANGELOG.md#dbt-redshift-190---december-09-2024) +- [dbt-snowflake 1.9.0](https://github.com/dbt-labs/dbt-snowflake/blob/1.9.latest/CHANGELOG.md#dbt-snowflake-190---december-09-2024) +- [dbt-spark 1.9.0](https://github.com/dbt-labs/dbt-spark/blob/1.9.latest/CHANGELOG.md#dbt-spark-190---december-10-2024) +- [dbt-synapse 1.8.2](https://github.com/microsoft/dbt-synapse/blob/v1.8.latest/CHANGELOG.md) +- [dbt-teradata 1.9.0](https://github.com/Teradata/dbt-teradata/releases/tag/v1.9.0) +- [dbt-trino 1.9.0](https://github.com/starburstdata/dbt-trino/blob/master/CHANGELOG.md#dbt-trino-190---december-20-2024) + + + ## December 2024 Release date: December 12, 2024 From 01346b8d23b02179917aff61e64c12297523336e Mon Sep 17 00:00:00 2001 From: Emily Rockman Date: Sat, 11 Jan 2025 09:31:08 -0600 Subject: [PATCH 11/28] =?UTF-8?q?since=20there=20aren=E2=80=99t=20any=20ch?= =?UTF-8?q?angelogs=20for=20cloud=20this=20time,=20no=20need=20to=20resolv?= =?UTF-8?q?e=20TODO=20this=20time?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- website/docs/docs/dbt-versions/compatible-track-changelog.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/website/docs/docs/dbt-versions/compatible-track-changelog.md b/website/docs/docs/dbt-versions/compatible-track-changelog.md index fd16d5076f4..348b9f26ce4 100644 --- a/website/docs/docs/dbt-versions/compatible-track-changelog.md +++ b/website/docs/docs/dbt-versions/compatible-track-changelog.md @@ -60,8 +60,6 @@ Changelogs: - [dbt-teradata 1.9.0](https://github.com/Teradata/dbt-teradata/releases/tag/v1.9.0) - [dbt-trino 1.9.0](https://github.com/starburstdata/dbt-trino/blob/master/CHANGELOG.md#dbt-trino-190---december-20-2024) - - ## December 2024 Release date: December 12, 2024 From e9f4955b4fd9e58b9e971e7458dd97eb440e1143 Mon Sep 17 00:00:00 2001 From: Mirna Wong <89008547+mirnawong1@users.noreply.github.com> Date: Mon, 13 Jan 2025 09:23:35 +0000 Subject: [PATCH 12/28] Update website/docs/reference/resource-configs/tags.md Co-authored-by: Matt Shaver <60105315+matthewshaver@users.noreply.github.com> --- website/docs/reference/resource-configs/tags.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/docs/reference/resource-configs/tags.md b/website/docs/reference/resource-configs/tags.md index cda0bec58b1..a25521d71ab 100644 --- a/website/docs/reference/resource-configs/tags.md +++ b/website/docs/reference/resource-configs/tags.md @@ -94,7 +94,7 @@ resource_type: -For example, to apply tags to a model in your `models/` directory, you would add the following using the `config` property: +To apply tags to a model in your `models/` directory, add the `config` property similar to the following example: From 0cd0fac4a80033e168b110150127cc2a91075b15 Mon Sep 17 00:00:00 2001 From: Mirna Wong <89008547+mirnawong1@users.noreply.github.com> Date: Mon, 13 Jan 2025 09:23:44 +0000 Subject: [PATCH 13/28] Update website/docs/reference/resource-configs/tags.md Co-authored-by: Matt Shaver <60105315+matthewshaver@users.noreply.github.com> --- website/docs/reference/resource-configs/tags.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/website/docs/reference/resource-configs/tags.md b/website/docs/reference/resource-configs/tags.md index a25521d71ab..547e13ecda4 100644 --- a/website/docs/reference/resource-configs/tags.md +++ b/website/docs/reference/resource-configs/tags.md @@ -144,6 +144,8 @@ You can use the [`+` operator](/reference/node-selection/graph-operators#the-plu :::tip Usage notes about tags +When using tags, consider the following: + - Tags are additive across project hierarchy. - Some resource types (like sources, exposures) require tags at the top level. From 10248cc0ae2115ab38a74fc42fe538da503f7b10 Mon Sep 17 00:00:00 2001 From: Mirna Wong <89008547+mirnawong1@users.noreply.github.com> Date: Mon, 13 Jan 2025 09:24:02 +0000 Subject: [PATCH 14/28] Update website/docs/reference/resource-configs/tags.md Co-authored-by: Matt Shaver <60105315+matthewshaver@users.noreply.github.com> --- website/docs/reference/resource-configs/tags.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/docs/reference/resource-configs/tags.md b/website/docs/reference/resource-configs/tags.md index 547e13ecda4..6fc8960af7c 100644 --- a/website/docs/reference/resource-configs/tags.md +++ b/website/docs/reference/resource-configs/tags.md @@ -187,7 +187,7 @@ models: ### Apply tags to models -This section shares how to apply tags to models in the `dbt_project.yml`, `schema.yml`, or SQL files, however you can also apply tags to individual resources. +This section demonstrates applying tags to models in the `dbt_project.yml`, `schema.yml`, and SQL files. To apply tags to a model in your `dbt_project.yml` file, you would add the following: From 9764ae0f3ca9e07674e3add06ee1e3ea37172e1e Mon Sep 17 00:00:00 2001 From: Mirna Wong <89008547+mirnawong1@users.noreply.github.com> Date: Mon, 13 Jan 2025 09:29:56 +0000 Subject: [PATCH 15/28] Update website/docs/reference/resource-configs/event-time.md Co-authored-by: Joel Labes --- website/docs/reference/resource-configs/event-time.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/docs/reference/resource-configs/event-time.md b/website/docs/reference/resource-configs/event-time.md index 2dfd17399ad..904e076ad8b 100644 --- a/website/docs/reference/resource-configs/event-time.md +++ b/website/docs/reference/resource-configs/event-time.md @@ -149,7 +149,7 @@ Set the `event_time` to the name of the field that represents the actual timesta However, if an ingestion date (like `loaded_at`, `ingested_at`, or `last_updated_at`) are the only timestamps you use, you can set `event_time` to these fields. Here are some considerations to keep in mind if you do this: - Using `last_updated_at` or `loaded_at` — May result in duplicate entries in the resulting table in the data warehouse over multiple runs. Setting an appropriate [lookback](/reference/resource-configs/lookback) value can reduce duplicates but it can't fully eliminate them since some updates outside the lookback window won't be processed. -- Using `ingested_at` — Represents when data was ingested, (not when the event occurred). This is less semantically meaningful for the underlying data and may require more filtering during query time. +- Using `ingested_at` — Because this column is created by your ingestion/EL tool instead of coming from the original source, it will change if/when you need to resync your connector for some reason. This means that data will be reprocessed and loaded into your warehouse for a second time against a second date. As long as this never happens (or you run a full refresh when it does), microbatches will be processed correctly when using `ingested_at`. Here are some examples of recommended and not recommended `event_time` columns: From 11b9f76649b211033c6a40c0d8f7e7f6406c63ed Mon Sep 17 00:00:00 2001 From: Mirna Wong <89008547+mirnawong1@users.noreply.github.com> Date: Mon, 13 Jan 2025 09:30:31 +0000 Subject: [PATCH 16/28] Update website/docs/reference/resource-configs/event-time.md Co-authored-by: Joel Labes --- website/docs/reference/resource-configs/event-time.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/docs/reference/resource-configs/event-time.md b/website/docs/reference/resource-configs/event-time.md index 904e076ad8b..efdf8785690 100644 --- a/website/docs/reference/resource-configs/event-time.md +++ b/website/docs/reference/resource-configs/event-time.md @@ -144,7 +144,7 @@ You can configure `event_time` for a [model](/docs/build/models), [seed](/docs/b ### Best practices -Set the `event_time` to the name of the field that represents the actual timestamp of the event (like `account_created_at`). The timestamp of the event should represent "at what time did the row occur" rather than an event ingestion date. +Set the `event_time` to the name of the field that represents the actual timestamp of the event (like `account_created_at`). The timestamp of the event should represent "at what time did the row occur" rather than an event ingestion date. Marking a column as the `event_time` when it isn't diverges from the semantic meaning of the column which may result in user confusion when other tools make use of the metadata. However, if an ingestion date (like `loaded_at`, `ingested_at`, or `last_updated_at`) are the only timestamps you use, you can set `event_time` to these fields. Here are some considerations to keep in mind if you do this: From 34fa8ce78c8e8390fb52f77298c80e5e135a54e2 Mon Sep 17 00:00:00 2001 From: Mirna Wong <89008547+mirnawong1@users.noreply.github.com> Date: Mon, 13 Jan 2025 09:31:52 +0000 Subject: [PATCH 17/28] Update website/docs/reference/resource-configs/event-time.md --- website/docs/reference/resource-configs/event-time.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/docs/reference/resource-configs/event-time.md b/website/docs/reference/resource-configs/event-time.md index efdf8785690..62bd4344287 100644 --- a/website/docs/reference/resource-configs/event-time.md +++ b/website/docs/reference/resource-configs/event-time.md @@ -149,7 +149,7 @@ Set the `event_time` to the name of the field that represents the actual timesta However, if an ingestion date (like `loaded_at`, `ingested_at`, or `last_updated_at`) are the only timestamps you use, you can set `event_time` to these fields. Here are some considerations to keep in mind if you do this: - Using `last_updated_at` or `loaded_at` — May result in duplicate entries in the resulting table in the data warehouse over multiple runs. Setting an appropriate [lookback](/reference/resource-configs/lookback) value can reduce duplicates but it can't fully eliminate them since some updates outside the lookback window won't be processed. -- Using `ingested_at` — Because this column is created by your ingestion/EL tool instead of coming from the original source, it will change if/when you need to resync your connector for some reason. This means that data will be reprocessed and loaded into your warehouse for a second time against a second date. As long as this never happens (or you run a full refresh when it does), microbatches will be processed correctly when using `ingested_at`. +- Using `ingested_at` — Since this column is created by your ingestion/EL tool instead of coming from the original source, it will change if/when you need to resync your connector for some reason. This means that data will be reprocessed and loaded into your warehouse for a second time against a second date. As long as this never happens (or you run a full refresh when it does), microbatches will be processed correctly when using `ingested_at`. Here are some examples of recommended and not recommended `event_time` columns: From 1938b58592888420bac18321355b71b69a61292f Mon Sep 17 00:00:00 2001 From: mirnawong1 Date: Mon, 13 Jan 2025 17:02:45 +0000 Subject: [PATCH 18/28] add callout tip --- website/docs/docs/build/unit-tests.md | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/website/docs/docs/build/unit-tests.md b/website/docs/docs/build/unit-tests.md index b7123fa35d6..1cda3ef71c7 100644 --- a/website/docs/docs/build/unit-tests.md +++ b/website/docs/docs/build/unit-tests.md @@ -10,9 +10,6 @@ keywords: - - - Historically, dbt's test coverage was confined to [“data” tests](/docs/build/data-tests), assessing the quality of input data or resulting datasets' structure. However, these tests could only be executed _after_ building a model. Starting in dbt Core v1.8, we have introduced an additional type of test to dbt - unit tests. In software programming, unit tests validate small portions of your functional code, and they work much the same way here. Unit tests allow you to validate your SQL modeling logic on a small set of static inputs _before_ you materialize your full model in production. Unit tests enable test-driven development, benefiting developer efficiency and code reliability. @@ -219,10 +216,19 @@ dbt test --select test_is_valid_email_address Your model is now ready for production! Adding this unit test helped catch an issue with the SQL logic _before_ you materialized `dim_customers` in your warehouse and will better ensure the reliability of this model in the future. - ## Unit testing incremental models -When configuring your unit test, you can override the output of macros, vars, or environment variables. This enables you to unit test your incremental models in "full refresh" and "incremental" modes. +When configuring your unit test, you can override the output of macros, vars, or environment variables. This enables you to unit test your incremental models in "full refresh" and "incremental" modes. + +:::tip +Incremental models need to exist in the database first before running unit tests or doing a `dbt build`. Use the [`--empty` flag](/reference/commands/build#the---empty-flag) to build an empty version of the models to save warehouse spend. You can also optionally select only your incremental models using the [`--select` flag](/reference/node-selection/syntax#shorthand). + + ```shell + dbt run --select "config.materialized:incremental" --empty + ``` + + After running the command, you can then perform a regular `dbt build` for that model and then run your unit test +::: When testing an incremental model, the expected output is the __result of the materialization__ (what will be merged/inserted), not the resulting model itself (what the final table will look like after the merge/insert). From f2190c6eca72d044801f53be3450ebc6dce4700d Mon Sep 17 00:00:00 2001 From: Mirna Wong <89008547+mirnawong1@users.noreply.github.com> Date: Mon, 13 Jan 2025 17:12:28 +0000 Subject: [PATCH 19/28] Update website/docs/docs/build/unit-tests.md Co-authored-by: Matt Shaver <60105315+matthewshaver@users.noreply.github.com> --- website/docs/docs/build/unit-tests.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/docs/docs/build/unit-tests.md b/website/docs/docs/build/unit-tests.md index 1cda3ef71c7..020f780dd84 100644 --- a/website/docs/docs/build/unit-tests.md +++ b/website/docs/docs/build/unit-tests.md @@ -227,7 +227,7 @@ Incremental models need to exist in the database first before running unit tests dbt run --select "config.materialized:incremental" --empty ``` - After running the command, you can then perform a regular `dbt build` for that model and then run your unit test + After running the command, you can then perform a regular `dbt build` for that model and then run your unit test. ::: When testing an incremental model, the expected output is the __result of the materialization__ (what will be merged/inserted), not the resulting model itself (what the final table will look like after the merge/insert). From 1275b30ebc5fc1f033e92858db7fd7f889fbb9bd Mon Sep 17 00:00:00 2001 From: Mirna Wong <89008547+mirnawong1@users.noreply.github.com> Date: Mon, 13 Jan 2025 17:14:36 +0000 Subject: [PATCH 20/28] Update website/docs/docs/build/unit-tests.md Co-authored-by: Matt Shaver <60105315+matthewshaver@users.noreply.github.com> --- website/docs/docs/build/unit-tests.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/docs/docs/build/unit-tests.md b/website/docs/docs/build/unit-tests.md index 020f780dd84..4a92a5792c9 100644 --- a/website/docs/docs/build/unit-tests.md +++ b/website/docs/docs/build/unit-tests.md @@ -220,7 +220,7 @@ Your model is now ready for production! Adding this unit test helped catch an is When configuring your unit test, you can override the output of macros, vars, or environment variables. This enables you to unit test your incremental models in "full refresh" and "incremental" modes. -:::tip +:::note Incremental models need to exist in the database first before running unit tests or doing a `dbt build`. Use the [`--empty` flag](/reference/commands/build#the---empty-flag) to build an empty version of the models to save warehouse spend. You can also optionally select only your incremental models using the [`--select` flag](/reference/node-selection/syntax#shorthand). ```shell From b4d2ce84b858395837d487425fea3313358da9d9 Mon Sep 17 00:00:00 2001 From: "Leona B. Campbell" <3880403+runleonarun@users.noreply.github.com> Date: Mon, 13 Jan 2025 15:13:20 -0500 Subject: [PATCH 21/28] Update customize-schema-alias.md (#6767) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit ## What are you changing in this pull request and why? Adding some keywords to help make this guide more discoverable in google searches. ## Checklist - [x] I have reviewed the [Content style guide](https://github.com/dbt-labs/docs.getdbt.com/blob/current/contributing/content-style-guide.md) so my content adheres to these guidelines. - [ ] The topic I'm writing about is for specific dbt version(s) and I have versioned it according to the [version a whole page](https://github.com/dbt-labs/docs.getdbt.com/blob/current/contributing/single-sourcing-content.md#adding-a-new-version) and/or [version a block of content](https://github.com/dbt-labs/docs.getdbt.com/blob/current/contributing/single-sourcing-content.md#versioning-blocks-of-content) guidelines. - [ ] I have added checklist item(s) to this list for anything anything that needs to happen before this PR is merged, such as "needs technical review" or "change base branch." - [ ] The content in this PR requires a dbt release note, so I added one to the [release notes page](https://docs.getdbt.com/docs/dbt-versions/dbt-cloud-release-notes). --- 🚀 Deployment available! Here are the direct links to the updated files: - https://docs-getdbt-com-git-runleonarun-patch-15-dbt-labs.vercel.app/guides/customize-schema-alias --------- Co-authored-by: Matt Shaver <60105315+matthewshaver@users.noreply.github.com> --- website/docs/guides/customize-schema-alias.md | 1 + 1 file changed, 1 insertion(+) diff --git a/website/docs/guides/customize-schema-alias.md b/website/docs/guides/customize-schema-alias.md index 28d4aada525..e9c3b95fc98 100644 --- a/website/docs/guides/customize-schema-alias.md +++ b/website/docs/guides/customize-schema-alias.md @@ -9,6 +9,7 @@ icon: 'guides' hide_table_of_contents: true level: 'Advanced' recently_updated: true +keywords: ["generate", "schema name", "guide", "dbt", "schema customization", "custom schema"] ---
From bfaf7c1fc4c29a2c9fe361f36796571bb43c720b Mon Sep 17 00:00:00 2001 From: Mirna Wong <89008547+mirnawong1@users.noreply.github.com> Date: Tue, 14 Jan 2025 11:47:47 +0000 Subject: [PATCH 22/28] Update deploy-jobs.md add more visibility to run job command behavior. raised by user in zendesk and [internal slack](https://dbt-labs.slack.com/archives/C02NCQ9483C/p1736520845461079) --- website/docs/docs/deploy/deploy-jobs.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/website/docs/docs/deploy/deploy-jobs.md b/website/docs/docs/deploy/deploy-jobs.md index 0505f1f228d..b9bc1b0ffa9 100644 --- a/website/docs/docs/deploy/deploy-jobs.md +++ b/website/docs/docs/deploy/deploy-jobs.md @@ -32,9 +32,9 @@ You can create a deploy job and configure it to run on [scheduled days and times - (Optional) **Description** — Provide a description of what the job does (for example, what the job consumes and what the job produces). - **Environment** — By default, it’s set to the deployment environment you created the deploy job from. 3. Options in the **Execution settings** section: - - **Commands** — By default, it includes the `dbt build` command. Click **Add command** to add more [commands](/docs/deploy/job-commands) that you want to be invoked when the job runs. - - **Generate docs on run** — Enable this option if you want to [generate project docs](/docs/collaborate/build-and-view-your-docs) when this deploy job runs. - - **Run source freshness** — Enable this option to invoke the `dbt source freshness` command before running the deploy job. Refer to [Source freshness](/docs/deploy/source-freshness) for more details. + - [**Commands**](/docs/deploy/job-commands#built-in-commands) — By default, it includes the `dbt build` command. Click **Add command** to add more [commands](/docs/deploy/job-commands) that you want to be invoked when the job runs. During a job run, [built-in commands](/docs/deploy/job-commands#built-in-commands) are "chained" together and if one run step fails, the entire job fails with an "Error" status. + - [**Generate docs on run**](/docs/deploy/job-commands#checkbox-commands) — Enable this option if you want to [generate project docs](/docs/collaborate/build-and-view-your-docs) when this deploy job runs. If the step fails, the job can succeed if subsequent steps pass. + - [**Run source freshness**](/docs/deploy/job-commands#checkbox-commands) — Enable this option to invoke the `dbt source freshness` command before running the deploy job. If the step fails, the job can succeed if subsequent steps pass. Refer to [Source freshness](/docs/deploy/source-freshness) for more details. 4. Options in the **Triggers** section: - **Run on schedule** — Run the deploy job on a set schedule. - **Timing** — Specify whether to [schedule](#schedule-days) the deploy job using **Intervals** that run the job every specified number of hours, **Specific hours** that run the job at specific times of day, or **Cron schedule** that run the job specified using [cron syntax](#cron-schedule). From ef6500d268af486092b0f06b88557075f8d5fcff Mon Sep 17 00:00:00 2001 From: Mirna Wong <89008547+mirnawong1@users.noreply.github.com> Date: Tue, 14 Jan 2025 13:19:46 +0000 Subject: [PATCH 23/28] Update event-time.md add comma --- website/docs/reference/resource-configs/event-time.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/docs/reference/resource-configs/event-time.md b/website/docs/reference/resource-configs/event-time.md index 62bd4344287..975c5059af1 100644 --- a/website/docs/reference/resource-configs/event-time.md +++ b/website/docs/reference/resource-configs/event-time.md @@ -144,7 +144,7 @@ You can configure `event_time` for a [model](/docs/build/models), [seed](/docs/b ### Best practices -Set the `event_time` to the name of the field that represents the actual timestamp of the event (like `account_created_at`). The timestamp of the event should represent "at what time did the row occur" rather than an event ingestion date. Marking a column as the `event_time` when it isn't diverges from the semantic meaning of the column which may result in user confusion when other tools make use of the metadata. +Set the `event_time` to the name of the field that represents the actual timestamp of the event (like `account_created_at`). The timestamp of the event should represent "at what time did the row occur" rather than an event ingestion date. Marking a column as the `event_time` when it isn't, diverges from the semantic meaning of the column which may result in user confusion when other tools make use of the metadata. However, if an ingestion date (like `loaded_at`, `ingested_at`, or `last_updated_at`) are the only timestamps you use, you can set `event_time` to these fields. Here are some considerations to keep in mind if you do this: From d5589c5e69fb3489b7f7023b3fc3d5c9165d8c98 Mon Sep 17 00:00:00 2001 From: mirnawong1 Date: Tue, 14 Jan 2025 16:04:25 +0000 Subject: [PATCH 24/28] add related docs link\ --- website/docs/docs/build/custom-aliases.md | 5 +++++ website/docs/docs/build/custom-databases.md | 6 ++++++ website/docs/docs/build/custom-schemas.md | 6 ++++++ 3 files changed, 17 insertions(+) diff --git a/website/docs/docs/build/custom-aliases.md b/website/docs/docs/build/custom-aliases.md index ae1d93e66a7..9a1e6b3a647 100644 --- a/website/docs/docs/build/custom-aliases.md +++ b/website/docs/docs/build/custom-aliases.md @@ -157,3 +157,8 @@ If these models should indeed have the same database identifier, you can work ar By default, dbt will create versioned models with the alias `_v`, where `` is that version's unique identifier. You can customize this behavior just like for non-versioned models by configuring a custom `alias` or re-implementing the `generate_alias_name` macro. +## Related docs + +- [Customize dbt models database, schema, and alias](/guides/customize-schema-alias?step=1) to learn how to customize dbt models database, schema, and alias +- [Custom schema](/docs/build/custom-schemas) to learn how to customize dbt schema +- [Custom database](/docs/build/custom-databases) to learn how to customize dbt database diff --git a/website/docs/docs/build/custom-databases.md b/website/docs/docs/build/custom-databases.md index 7a607534230..51a515db807 100644 --- a/website/docs/docs/build/custom-databases.md +++ b/website/docs/docs/build/custom-databases.md @@ -98,3 +98,9 @@ See docs on macro `dispatch`: ["Managing different global overrides across packa ### BigQuery When dbt opens a BigQuery connection, it will do so using the `project_id` defined in your active `profiles.yml` target. This `project_id` will be billed for the queries that are executed in the dbt run, even if some models are configured to be built in other projects. + +## Related docs + +- [Customize dbt models database, schema, and alias](/guides/customize-schema-alias?step=1) to learn how to customize dbt models database, schema, and alias +- [Custom schema](/docs/build/custom-schemas) to learn how to customize dbt model schema +- [Custom alias](/docs/build/custom-aliases) to learn how to customize dbt model alias name diff --git a/website/docs/docs/build/custom-schemas.md b/website/docs/docs/build/custom-schemas.md index 6dabf56943c..fb62b5c926a 100644 --- a/website/docs/docs/build/custom-schemas.md +++ b/website/docs/docs/build/custom-schemas.md @@ -207,3 +207,9 @@ In the `generate_schema_name` macro examples shown in the [built-in alternative If your schema names are being generated incorrectly, double-check your target name in the relevant environment. For more information, consult the [managing environments in dbt Core](/docs/core/dbt-core-environments) guide. + +## Related docs + +- [Customize dbt models database, schema, and alias](/guides/customize-schema-alias?step=1) to learn how to customize dbt models database, schema, and alias +- [Custom database](/docs/build/custom-databases) to learn how to customize dbt model database +- [Custom aliases](/docs/build/custom-aliases) to learn how to customize dbt model alias name From b903ea58313cef6cc059f21e332544b1b77bb0d7 Mon Sep 17 00:00:00 2001 From: mirnawong1 Date: Tue, 14 Jan 2025 16:04:44 +0000 Subject: [PATCH 25/28] add s --- website/docs/docs/build/custom-databases.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/docs/docs/build/custom-databases.md b/website/docs/docs/build/custom-databases.md index 51a515db807..a336f50c9f5 100644 --- a/website/docs/docs/build/custom-databases.md +++ b/website/docs/docs/build/custom-databases.md @@ -103,4 +103,4 @@ When dbt opens a BigQuery connection, it will do so using the `project_id` defin - [Customize dbt models database, schema, and alias](/guides/customize-schema-alias?step=1) to learn how to customize dbt models database, schema, and alias - [Custom schema](/docs/build/custom-schemas) to learn how to customize dbt model schema -- [Custom alias](/docs/build/custom-aliases) to learn how to customize dbt model alias name +- [Custom aliases](/docs/build/custom-aliases) to learn how to customize dbt model alias name From 26cd01dd7011e44ef83e2f68dfcdd0e9457ba961 Mon Sep 17 00:00:00 2001 From: Natalie Fiann Date: Wed, 15 Jan 2025 09:51:07 +0000 Subject: [PATCH 26/28] Updated Microsoft Excel doc to add additional info on 1 min time limit --- website/docs/docs/cloud-integrations/semantic-layer/excel.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/docs/docs/cloud-integrations/semantic-layer/excel.md b/website/docs/docs/cloud-integrations/semantic-layer/excel.md index c80040dce01..792e90a2e67 100644 --- a/website/docs/docs/cloud-integrations/semantic-layer/excel.md +++ b/website/docs/docs/cloud-integrations/semantic-layer/excel.md @@ -36,7 +36,7 @@ import Tools from '/snippets/_sl-excel-gsheets.md'; From e870efbc4637996b6bca426cdc8f03684b727967 Mon Sep 17 00:00:00 2001 From: nataliefiann <120089939+nataliefiann@users.noreply.github.com> Date: Wed, 15 Jan 2025 10:41:39 +0000 Subject: [PATCH 27/28] Update website/docs/docs/cloud-integrations/semantic-layer/excel.md Co-authored-by: Mirna Wong <89008547+mirnawong1@users.noreply.github.com> --- website/docs/docs/cloud-integrations/semantic-layer/excel.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/docs/docs/cloud-integrations/semantic-layer/excel.md b/website/docs/docs/cloud-integrations/semantic-layer/excel.md index 792e90a2e67..6da7edce3fe 100644 --- a/website/docs/docs/cloud-integrations/semantic-layer/excel.md +++ b/website/docs/docs/cloud-integrations/semantic-layer/excel.md @@ -36,7 +36,7 @@ import Tools from '/snippets/_sl-excel-gsheets.md'; From 104e8c1f302fd3ba3978d2265629c2ee5bc2d262 Mon Sep 17 00:00:00 2001 From: diegomorales-dbtlabs Date: Thu, 16 Jan 2025 12:55:48 +1300 Subject: [PATCH 28/28] Update data-tests.md (clarify usage of singular tests in the `tests` directory) (#6780) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit clarify usage of singular tests in the `tests` directory Added a note to explain that singular tests in the `tests` directory are automatically executed during `dbt test` and should not be referenced in `schema.yml` to avoid errors. as explained in this post https://discourse.getdbt.com/t/custom-test-not-recognized/12036 ## What are you changing in this pull request and why? ## Checklist - [ ] I have reviewed the [Content style guide](https://github.com/dbt-labs/docs.getdbt.com/blob/current/contributing/content-style-guide.md) so my content adheres to these guidelines. - [ ] The topic I'm writing about is for specific dbt version(s) and I have versioned it according to the [version a whole page](https://github.com/dbt-labs/docs.getdbt.com/blob/current/contributing/single-sourcing-content.md#adding-a-new-version) and/or [version a block of content](https://github.com/dbt-labs/docs.getdbt.com/blob/current/contributing/single-sourcing-content.md#versioning-blocks-of-content) guidelines. - [ ] I have added checklist item(s) to this list for anything anything that needs to happen before this PR is merged, such as "needs technical review" or "change base branch." - [ ] The content in this PR requires a dbt release note, so I added one to the [release notes page](https://docs.getdbt.com/docs/dbt-versions/dbt-cloud-release-notes). --- 🚀 Deployment available! Here are the direct links to the updated files: - https://docs-getdbt-com-git-diegomorales-dbtlabs-patch-1-dbt-labs.vercel.app/docs/build/data-tests --------- Co-authored-by: Matt Shaver <60105315+matthewshaver@users.noreply.github.com> --- website/docs/docs/build/data-tests.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/website/docs/docs/build/data-tests.md b/website/docs/docs/build/data-tests.md index 559fe468644..24c468b976d 100644 --- a/website/docs/docs/build/data-tests.md +++ b/website/docs/docs/build/data-tests.md @@ -73,7 +73,9 @@ having total_amount < 0 The name of this test is the name of the file: `assert_total_payment_amount_is_positive`. -Note, you won't need to include semicolons (;) at the end of the SQL statement in your singular test files as it can cause your test to fail. +Note: +- Omit semicolons (;) at the end of the SQL statement in your singular test files, as they can cause your test to fail. +- Singular tests placed in the tests directory are automatically executed when running `dbt test`. Don't reference singular tests in `model_name.yml`, as they are not treated as generic tests or macros, and doing so will result in an error. To add a description to a singular test in your project, add a `.yml` file to your `tests` directory, for example, `tests/schema.yml` with the following content: