Merge branch 'current' into update-vale

website/blog/2022-04-14-add-ci-cd-to-bitbucket.md

@@ -197,7 +197,7 @@ Reading the file over, you can see that we:
 
 In summary, anytime anything is pushed to main, we’ll ensure our production database reflects the dbt transformation, and we’ve saved the resulting artifacts to defer to.
 
-> ❓ **What are artifacts and why should I defer to them?** dbt artifacts are metadata of the last run - what models and tests were defined, which ones ran successfully, and which failed. If a future dbt run is set to ***defer*** to this metadata, it means that it can select models and tests to run based on their state, including and especially their difference from the reference metadata. See [Artifacts](https://docs.getdbt.com/reference/artifacts/dbt-artifacts), [Selection methods: “state”](https://docs.getdbt.com/reference/node-selection/methods#the-state-method), and [Caveats to state comparison](https://docs.getdbt.com/reference/node-selection/state-comparison-caveats) for details.
+> ❓ **What are artifacts and why should I defer to them?** dbt artifacts are metadata of the last run - what models and tests were defined, which ones ran successfully, and which failed. If a future dbt run is set to ***defer*** to this metadata, it means that it can select models and tests to run based on their state, including and especially their difference from the reference metadata. See [Artifacts](https://docs.getdbt.com/reference/artifacts/dbt-artifacts), [Selection methods: “state”](https://docs.getdbt.com/reference/node-selection/methods#state), and [Caveats to state comparison](https://docs.getdbt.com/reference/node-selection/state-comparison-caveats) for details.
 
 ### Slim Continuous Integration: Retrieve the artifacts and do a state-based run
 

website/docs/docs/build/dbt-tips.md

@@ -40,7 +40,7 @@ Leverage these dbt packages to streamline your workflow:
 - Set `vars` in your `dbt_project.yml` to define global defaults for certain conditions, which you can then override using the `--vars` flag in your commands.
 - Use [for loops](/guides/using-jinja?step=3) in Jinja to <Term id="dry">DRY</Term> up repetitive logic, such as selecting a series of columns that all require the same transformations and naming patterns to be applied.
 - Instead of relying on post-hooks, use the [grants config](/reference/resource-configs/grants) to apply permission grants in the warehouse resiliently.
-- Define [source-freshness](/docs/build/sources#snapshotting-source-data-freshness) thresholds on your sources to avoid running transformations on data that has already been processed.
+- Define [source-freshness](/docs/build/sources#source-data-freshness) thresholds on your sources to avoid running transformations on data that has already been processed.
 - Use the `+` operator on the left of a model `dbt build --select +model_name` to run a model and all of its upstream dependencies. Use the `+` operator on the right of the model `dbt build --select model_name+` to run a model and everything downstream that depends on it.
 - Use `dir_name` to run all models in a package or directory.
 - Use the `@` operator on the left of a model in a non-state-aware CI setup to test it. This operator runs all of a selection’s parents and children, and also runs the parents of its children, which in a fresh CI schema will likely not exist yet.

website/docs/docs/build/exposures.md

@@ -77,5 +77,5 @@ When we generate the [dbt Explorer site](/docs/collaborate/explore-projects), yo
 ## Related docs
 
 * [Exposure properties](/reference/exposure-properties)
-* [`exposure:` selection method](/reference/node-selection/methods#the-exposure-method)
+* [`exposure:` selection method](/reference/node-selection/methods#exposure)
 * [Data health tiles](/docs/collaborate/data-tile)

website/docs/docs/build/groups.md

@@ -119,4 +119,4 @@ dbt.exceptions.DbtReferenceError: Parsing Error
 
 * [Model Access](/docs/collaborate/govern/model-access#groups)
 * [Group configuration](/reference/resource-configs/group)
-* [Group selection](/reference/node-selection/methods#the-group-method)
+* [Group selection](/reference/node-selection/methods#group)

website/docs/docs/build/materializations.md

@@ -18,7 +18,11 @@ You can also configure [custom materializations](/guides/create-new-materializat
 
 
 ## Configuring materializations
-By default, dbt models are materialized as "views". Models can be configured with a different materialization by supplying the `materialized` configuration parameter as shown below.
+By default, dbt models are materialized as "views". Models can be configured with a different materialization by supplying the [`materialized` configuration](/reference/resource-configs/materialized) parameter as shown in the following tabs.
+
+<Tabs>
+
+<TabItem value="Project file">
 
 <File name='dbt_project.yml'>
 
@@ -49,6 +53,10 @@ models:
 
 </File>
 
+</TabItem>
+
+<TabItem value="Model file">
+
 Alternatively, materializations can be configured directly inside of the model sql files. This can be useful if you are also setting [Performance Optimization] configs for specific models (for example, [Redshift specific configurations](/reference/resource-configs/redshift-configs) or [BigQuery specific configurations](/reference/resource-configs/bigquery-configs)).
 
 <File name='models/events/stg_event_log.sql'>
@@ -63,6 +71,29 @@ from ...
 
 </File>
 
+</TabItem>
+
+<TabItem value="Property file">
+
+Materializations can also be configured in the model's `properties.yml` file.  The following example shows the `table` materialization type. For a complete list of materialization types, refer to [materializations](/docs/build/materializations#materializations).
+
+<File name='models/properties.yml'>
+
+```yaml
+version: 2
+
+models:
+  - name: events
+    config:
+      materialized: table
+```
+
+</File>
+
+</TabItem>
+
+</Tabs>
+
 ## Materializations
 
 

website/docs/docs/build/sources.md

@@ -130,11 +130,11 @@ You can find more details on the available properties for sources in the [refere
 <FAQ path="Tests/testing-sources" />
 <FAQ path="Runs/running-models-downstream-of-source" />
 
-## Snapshotting source data freshness
-With a couple of extra configs, dbt can optionally snapshot the "freshness" of the data in your source tables. This is useful for understanding if your data pipelines are in a healthy state, and is a critical component of defining SLAs for your warehouse.
+## Source data freshness
+With a couple of extra configs, dbt can optionally capture the "freshness" of the data in your source tables. This is useful for understanding if your data pipelines are in a healthy state, and is a critical component of defining SLAs for your warehouse.
 
 ### Declaring source freshness
-To configure sources to snapshot freshness information, add a `freshness` block to your source and `loaded_at_field` to your table declaration:
+To configure source freshness information, add a `freshness` block to your source and `loaded_at_field` to your table declaration:
 
 <File name='models/<filename>.yml'>
 
@@ -164,14 +164,14 @@ sources:
 
 </File>
 
-In the `freshness` block, one or both of `warn_after` and `error_after` can be provided. If neither is provided, then dbt will not calculate freshness snapshots for the tables in this source.
+In the `freshness` block, one or both of `warn_after` and `error_after` can be provided. If neither is provided, then dbt will not calculate freshness for the tables in this source.
 
 Additionally, the `loaded_at_field` is required to calculate freshness for a table. If a `loaded_at_field` is not provided, then dbt will not calculate freshness for the table.
 
 These configs are applied hierarchically, so `freshness` and `loaded_at_field` values specified for a `source` will flow through to all of the `tables` defined in that source. This is useful when all of the tables in a source have the same `loaded_at_field`, as the config can just be specified once in the top-level source definition.
 
 ### Checking source freshness
-To snapshot freshness information for your sources, use the `dbt source freshness` command ([reference docs](/reference/commands/source)):
+To obtain freshness information for your sources, use the `dbt source freshness` command ([reference docs](/reference/commands/source)):
 
 ```
 $ dbt source freshness
@@ -182,7 +182,7 @@ Behind the scenes, dbt uses the freshness properties to construct a `select` que
 ```sql
 select
   max(_etl_loaded_at) as max_loaded_at,
-  convert_timezone('UTC', current_timestamp()) as snapshotted_at
+  convert_timezone('UTC', current_timestamp()) as calculated_at
 from raw.jaffle_shop.orders
 
 ```
@@ -198,7 +198,7 @@ Some databases can have tables where a filter over certain columns are required,
 ```sql
 select
   max(_etl_loaded_at) as max_loaded_at,
-  convert_timezone('UTC', current_timestamp()) as snapshotted_at
+  convert_timezone('UTC', current_timestamp()) as calculated_at
 from raw.jaffle_shop.orders
 where _etl_loaded_at >= date_sub(current_date(), interval 1 day)
 ```

website/docs/docs/collaborate/govern/model-versions.md

@@ -99,7 +99,7 @@ Let's say that `dim_customers` has three versions defined: `v2` is the "latest",
 
 As you'll see in the implementation section below, a versioned model can reuse the majority of its YAML properties and configuration. Each version needs to only say how it _differs_ from the shared set of attributes. This gives you, as the producer of a versioned model, the opportunity to highlight the differences across versions—which is otherwise difficult to detect in models with dozens or hundreds of columns—and to clearly track, in one place, all versions of the model which are currently live.
 
-dbt also supports [`version`-based selection](/reference/node-selection/methods#the-version-method). For example, you could define a [default YAML selector](/reference/node-selection/yaml-selectors#default) that avoids running any old model versions in development, even while you continue to run them in production through a sunset and migration period. (You could accomplish something similar by applying `tags` to these models, and cycling through those tags over time.)
+dbt also supports [`version`-based selection](/reference/node-selection/methods#version). For example, you could define a [default YAML selector](/reference/node-selection/yaml-selectors#default) that avoids running any old model versions in development, even while you continue to run them in production through a sunset and migration period. (You could accomplish something similar by applying `tags` to these models, and cycling through those tags over time.)
 
 <File name="selectors.yml">
 

website/docs/docs/dbt-cloud-apis/discovery-use-cases-and-examples.md

@@ -495,7 +495,7 @@ Graph example:
 
 ### Are my data sources fresh?
 
-Checking [source freshness](/docs/build/sources#snapshotting-source-data-freshness) allows you to ensure that sources loaded and used in your dbt project are compliant with expectations. The API provides the latest metadata about source loading and information about the freshness check criteria.
+Checking [source freshness](/docs/build/sources#source-data-freshness) allows you to ensure that sources loaded and used in your dbt project are compliant with expectations. The API provides the latest metadata about source loading and information about the freshness check criteria.
 
 <Lightbox src="/img/docs/dbt-cloud/discovery-api/source-freshness-page.png" width="75%" title="Source freshness page in dbt Cloud"/>
 

website/docs/docs/dbt-versions/core-upgrade/07-upgrading-to-v1.8.md

@@ -46,7 +46,7 @@ Historically, dbt's test coverage was confined to [“data” tests](/docs/build
 
 In v1.8, we're introducing native support for [unit testing](/docs/build/unit-tests). Unit tests validate your SQL modeling logic on a small set of static inputs __before__ you materialize your full model in production. They support a test-driven development approach, improving both the efficiency of developers and the reliability of code.
 
-Starting from v1.8, when you execute the `dbt test` command, it will run both unit and data tests. Use the [`test_type`](/reference/node-selection/methods#the-test_type-method) method to run only unit or data tests:
+Starting from v1.8, when you execute the `dbt test` command, it will run both unit and data tests. Use the [`test_type`](/reference/node-selection/methods#test_type) method to run only unit or data tests:
 
 ```shell
 

website/docs/docs/dbt-versions/core-upgrade/09-upgrading-to-v1.6.md

@@ -101,7 +101,7 @@ The ability for installed packages to override built-in materializations without
 
 ### Quick hits
 
-- [`state:unmodified` and `state:old`](/reference/node-selection/methods#the-state-method) for [MECE](https://en.wikipedia.org/wiki/MECE_principle) stateful selection
+- [`state:unmodified` and `state:old`](/reference/node-selection/methods#state) for [MECE](https://en.wikipedia.org/wiki/MECE_principle) stateful selection
 - [`invocation_args_dict`](/reference/dbt-jinja-functions/flags#invocation_args_dict) includes full `invocation_command` as string
 - [`dbt debug --connection`](/reference/commands/debug) to test just the data platform connection specified in a profile
 - [`dbt docs generate --empty-catalog`](/reference/commands/cmd-docs) to skip catalog population while generating docs

website/docs/docs/dbt-versions/core-upgrade/11-Older versions/13-upgrading-to-v1.3.md

@@ -54,5 +54,5 @@ GitHub discussion with details: [dbt-labs/dbt-core#6011](https://github.com/dbt-
 
 ### Quick hits
 - **["Full refresh"](/reference/resource-configs/full_refresh)** flag supports a short name, `-f`.
-- **[The "config" selection method](/reference/node-selection/methods#the-config-method)** supports boolean and list config values, in addition to strings.
+- **[The "config" selection method](/reference/node-selection/methods#config)** supports boolean and list config values, in addition to strings.
 - Two new dbt-Jinja context variables for accessing invocation metadata: [`invocation_args_dict`](/reference/dbt-jinja-functions/flags#invocation_args_dict) and [`dbt_metadata_envs`](/reference/dbt-jinja-functions/env_var#custom-metadata).

website/docs/docs/dbt-versions/core-upgrade/11-Older versions/14-upgrading-to-v1.2.md

@@ -32,7 +32,7 @@ See GitHub discussion [dbt-labs/dbt-core#5468](https://github.com/dbt-labs/dbt-c
 - **[Grants](/reference/resource-configs/grants)** are natively supported in `dbt-core` for the first time. That support extends to all standard materializations, and the most popular adapters. If you already use hooks to apply simple grants, we encourage you to use built-in `grants` to configure your models, seeds, and snapshots instead. This will enable you to [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) up your duplicated or boilerplate code.
 - **[Metrics](/docs/build/build-metrics-intro)** now support an `expression` type (metrics-on-metrics), as well as a `metric()` function to use when referencing metrics from within models, macros, or `expression`-type metrics. For more information on how to use expression metrics, check out the [**`dbt_metrics` package**](https://github.com/dbt-labs/dbt_metrics)
 - **[dbt-Jinja functions](/reference/dbt-jinja-functions)** now include the [`itertools` Python module](/reference/dbt-jinja-functions/modules#itertools), as well as the [set](/reference/dbt-jinja-functions/set) and [zip](/reference/dbt-jinja-functions/zip) functions.
-- **[Node selection](/reference/node-selection/syntax)** includes a [file selection method](/reference/node-selection/methods#the-file-method) (`-s model.sql`), and [yaml selector](/reference/node-selection/yaml-selectors) inheritance.
+- **[Node selection](/reference/node-selection/syntax)** includes a [file selection method](/reference/node-selection/methods#file) (`-s model.sql`), and [yaml selector](/reference/node-selection/yaml-selectors) inheritance.
 - **[Global configs](/reference/global-configs/about-global-configs)** now include CLI flag and environment variable settings for [`target-path`](/reference/global-configs/json-artifacts) and [`log-path`](/reference/global-configs/logs), which can be used to override the values set in `dbt_project.yml`
 
 ### Specific adapters

website/docs/docs/dbt-versions/core-upgrade/11-Older versions/15-upgrading-to-v1.1.md

@@ -45,7 +45,7 @@ Expected a schema version of "https://schemas.getdbt.com/dbt/manifest/v5.json" i
 
 ### Advanced and experimental functionality
 
-**Fresh Rebuilds.** There's a new _experimental_ selection method in town: [`source_status:fresher`](/reference/node-selection/methods#the-source_status-method). Much like the `state:` and `result` methods, the goal is to use dbt metadata to run your DAG more efficiently. If dbt has access to previous and current results of `dbt source freshness` (the `sources.json` artifact), dbt can compare them to determine which sources have loaded new data, and select only resources downstream of "fresher" sources. Read more in [Understanding State](/reference/node-selection/syntax#about-node-selection) and [CI/CD in dbt Cloud](/docs/deploy/continuous-integration).
+**Fresh Rebuilds.** There's a new _experimental_ selection method in town: [`source_status:fresher`](/reference/node-selection/methods#source_status). Much like the `state:` and `result` methods, the goal is to use dbt metadata to run your DAG more efficiently. If dbt has access to previous and current results of `dbt source freshness` (the `sources.json` artifact), dbt can compare them to determine which sources have loaded new data, and select only resources downstream of "fresher" sources. Read more in [Understanding State](/reference/node-selection/syntax#about-node-selection) and [CI/CD in dbt Cloud](/docs/deploy/continuous-integration).
 
 
 [**dbt-Jinja functions**](/reference/dbt-jinja-functions) have a new landing page, and two new members:

website/docs/docs/dbt-versions/core-upgrade/11-Older versions/upgrading-to-0-17-0.md

@@ -247,7 +247,7 @@ BigQuery:
 ## New and changed documentation
 
 **Core**
-- [`path:` selectors](/reference/node-selection/methods#the-path-method)
+- [`path:` selectors](/reference/node-selection/methods#path)
 - [`--fail-fast` command](/reference/commands/run#failing-fast)
 - `as_text` Jinja filter: removed this defunct filter
 - [accessing nodes in the `graph` object](/reference/dbt-jinja-functions/graph)

website/docs/docs/deploy/artifacts.md

@@ -4,7 +4,7 @@ id: "artifacts"
 description: "Use artifacts to power your automated docs site and source freshness data." 
 ---
 
-When running dbt jobs, dbt Cloud generates and saves *artifacts*. You can use these artifacts, like `manifest.json`, `catalog.json`, and `sources.json` to power different aspects of dbt Cloud, namely: [dbt Explorer](/docs/collaborate/explore-projects), [dbt Docs](/docs/collaborate/build-and-view-your-docs#dbt-docs), and [source freshness reporting](/docs/build/sources#snapshotting-source-data-freshness).
+When running dbt jobs, dbt Cloud generates and saves *artifacts*. You can use these artifacts, like `manifest.json`, `catalog.json`, and `sources.json` to power different aspects of dbt Cloud, namely: [dbt Explorer](/docs/collaborate/explore-projects), [dbt Docs](/docs/collaborate/build-and-view-your-docs#dbt-docs), and [source freshness reporting](/docs/build/sources#source-data-freshness).
 
 ## Create dbt Cloud Artifacts
 

website/docs/docs/deploy/ci-jobs.md

@@ -146,7 +146,7 @@ For semantic nodes and models that aren't downstream of modified models, dbt Clo
 
 <Expandable alt_header="Semantic nodes that are modified or affected by downstream modified nodes.">
 
-To only validate modified semantic nodes, use the following command (with [state selection](/reference/node-selection/syntax#stateful-selection)):
+To only validate modified semantic nodes, use the following command (with [state selection](/reference/node-selection/syntax#state-selection)):
 
 ```bash
 dbt sl validate --select state:modified+