Merge branch 'current' into mwong-remove-callout

dbt-labs · Nov 8, 2023 · 1e7faba · 1e7faba
2 parents 699782a + 050ae3e
commit 1e7faba
Show file tree

Hide file tree

Showing 6 changed files with 66 additions and 40 deletions.
diff --git a/contributing/content-style-guide.md b/contributing/content-style-guide.md
@@ -495,6 +495,14 @@ dbt officially provides two command line tools for running dbt commands:
 - [dbt Cloud CLI](/docs/cloud/cloud-cli-installation) &mdash; This tool allows you to develop locally and execute dbt commands against your dbt Cloud development environment from your local command line.
 - [dbt Core](https://github.com/dbt-labs/dbt-core) &mdash; This open-source tool is designed for local installation, enabling you to use dbt Core on the command line and communicate with databases through adapters.
 
+Here are some examples of what to use and what to avoid: <br />
+
+✅ Set up in the dbt Cloud CLI or dbt Core<br />
+✅ Set up in the dbt Cloud CLI or dbt Core CLI<br />
+
+❌ Set up via dbt CLI<br />
+❌ Set up in dbt Cloud, **or** via the CLI<br />
+
 ### Terms to use or avoid
 
 Use industry-specific terms and research new/improved terminology. Also, refer to the Inclusive Language section of this style guide for inclusive and accessible language and style. 

diff --git a/website/docs/docs/cloud/secure/ip-restrictions.md b/website/docs/docs/cloud/secure/ip-restrictions.md
@@ -36,7 +36,7 @@ To add an IP to the allowlist, from the **IP Restrictions** page:
 4. Select **Allow**
 5. Add the ranges in the CIDR notation
 	- For example, 1.1.1.1/8
-	- You cannot add multiple ranges in the same rule. Instead, create a rule per CIDR range.
+	- You can add multiple ranges in the same rule.
 6. Click **Save**
 
 Note that simply adding the IP Ranges will not enforce IP restrictions. For more information, see the section “Enabling Restrictions.”

diff --git a/website/docs/reference/resource-configs/enabled.md b/website/docs/reference/resource-configs/enabled.md
@@ -261,20 +261,26 @@ Support for disabling semantic models has been added in dbt Core v1.7
 
 <VersionBlock firstVersion="1.7">
 
-<File name='semantic_models.yml'>
-
-```yml
-semantic_models:
-  - name: semantic_people
-    model: ref('people')
-    config:
-      enabled: false
+<File name='dbt_project.yml'>
 
+```yaml
+semantic-models:
+  [<resource-path>](/reference/resource-configs/resource-path):
+    [+](/reference/resource-configs/plus-prefix)enabled: true | false
 ```
 
 </File>
 
-The `enabled` configuration can be nested under the `config` key.
+<File name='models/semantic_models.yml'>
+
+```yaml
+semantic_models:
+  - name: [<semantic_model_name>]
+    [config](/reference/resource-properties/config):
+      enabled: true | false
+```
+
+</File>
 
 </VersionBlock>
 
@@ -283,7 +289,7 @@ The `enabled` configuration can be nested under the `config` key.
 </Tabs>
 
 ## Definition
-An optional configuration for disabling models, seeds, snapshots, tests, and semantic models.
+An optional configuration for enabling or disabling a resource.
 
 * Default: true
 

diff --git a/website/docs/reference/resource-configs/group.md b/website/docs/reference/resource-configs/group.md
@@ -29,8 +29,6 @@ Support for grouping models was added in dbt Core v1.5
 
 <VersionBlock firstVersion="1.5">
 
-</VersionBlock>
-
 <File name='models/schema.yml'>
 
 ```yml
@@ -68,6 +66,8 @@ select ...
 
 </File>
 
+</VersionBlock>
+
 </TabItem>
 
 <TabItem value="seeds">
@@ -80,8 +80,6 @@ Support for grouping seeds was added in dbt Core v1.5
 
 <VersionBlock firstVersion="1.5">
 
-</VersionBlock>
-
 <File name='dbt_project.yml'>
 
 ```yml
@@ -102,6 +100,8 @@ seeds:
 
 </File>
 
+</VersionBlock>
+
 
 </TabItem>
 
@@ -115,8 +115,6 @@ Support for grouping snapshots was added in dbt Core v1.5
 
 <VersionBlock firstVersion="1.5">
 
-</VersionBlock>
-
 <File name='dbt_project.yml'>
 
 ```yml
@@ -143,6 +141,8 @@ select ...
 
 </File>
 
+</VersionBlock>
+
 
 </TabItem>
 
@@ -156,8 +156,6 @@ Support for grouping tests was added in dbt Core v1.5
 
 <VersionBlock firstVersion="1.5">
 
-</VersionBlock>
-
 <File name='dbt_project.yml'>
 
 ```yml
@@ -210,6 +208,8 @@ select ...
 
 </File>
 
+</VersionBlock>
+
 </TabItem>
 
 <TabItem value="analyses">
@@ -239,8 +239,6 @@ Support for grouping metrics was added in dbt Core v1.5
 
 <VersionBlock firstVersion="1.5">
 
-</VersionBlock>
-
 <File name='dbt_project.yml'>
 
 ```yaml
@@ -264,8 +262,11 @@ metrics:
 
 </File>
 
+</VersionBlock>
+
 </TabItem>
 
+
 <TabItem value="semantic models">
 
 <VersionBlock lastVersion="1.6">
@@ -276,37 +277,35 @@ Support for grouping semantic models has been added in dbt Core v1.7.
 
 <VersionBlock firstVersion="1.7">
 
-<File name='schema.yml'>
+<File name='models/semantic_models.yml'>
 
-```yml
+```yaml
 semantic_models:
-  - name: model_name
-    group: finance
+  - name: <semantic_model_name>
+    group: <group_name>
 
 ```
 
 </File>
 
 <File name='dbt_project.yml'>
 
-```yml
-semantic_models:
+```yaml
+semantic-models:
   [<resource-path>](resource-path):
-    +group: finance
+    [+](plus-prefix)group: <group_name>
 ```
 
 </File>
 
-The `group` configuration can be nested under the `config` key.
-
 </VersionBlock>
 
 </TabItem>
 
 </Tabs>
 
 ## Definition
-An optional configuration for grouping models, analysis, snapshots, tests, and metrics. When a resource is grouped, dbt will allow it to reference private models within the same group.
+An optional configuration for assigning a group to a resource. When a resource is grouped, dbt will allow it to reference private models within the same group.
 
 For more details on reference access between resources in groups, check out [model access](/docs/collaborate/govern/model-access#groups).
 

diff --git a/website/docs/reference/resource-configs/meta.md b/website/docs/reference/resource-configs/meta.md
@@ -184,20 +184,20 @@ Support for grouping semantic models was added in dbt Core v1.7
 
 <VersionBlock firstVersion="1.7"> 
 
-<File name='semantic_models.yml'>
+<File name='models/semantic_models.yml'>
 
 ```yml
 semantic_models:
-  - name: semantic_people
-    model: ref('people')
+  - name: semantic_model_name
     config:
       meta: {<dictionary>}
 
 ```
-The `meta` configuration can be nusted under the `config` key. 
 
 </File>
 
+The `meta` config can also be defined under the `semantic-models` config block in `dbt_project.yml`. See [configs and properties](/reference/configs-and-properties) for details.
+
 </VersionBlock>
 
 </TabItem>
@@ -207,7 +207,7 @@ The `meta` configuration can be nusted under the `config` key.
 ## Definition
 The `meta` field can be used to set metadata for a resource. This metadata is compiled into the `manifest.json` file generated by dbt, and is viewable in the auto-generated documentation.
 
-Depending on the resource you're configuring, `meta` may be available within the `config` property, or as a top-level key. (For backwards compatibility, `meta` is always supported as a top-level key, though without the capabilities of config inheritance.)
+Depending on the resource you're configuring, `meta` may be available within the `config` property, and/or as a top-level key. (For backwards compatibility, `meta` is often (but not always) supported as a top-level key, though without the capabilities of config inheritance.)
 
 
 ## Examples

diff --git a/website/docs/reference/resource-configs/pre-hook-post-hook.md b/website/docs/reference/resource-configs/pre-hook-post-hook.md
@@ -175,13 +175,17 @@ If multiple instances of any hooks are defined, dbt will run each hook using the
 
 
 ### Transaction behavior
-If you're using an adapter that makes use of transactions (namely Postgres or Redshift), it's worth noting that by default hooks are executed inside of the same transaction as your model being created.
+If you're using an adapter that uses transactions (namely Postgres or Redshift), it's worth noting that by default hooks are executed inside of the same transaction as your model being created.
 
 There may be occasions where you need to run these hooks _outside_ of a transaction, for example:
-* You want to run a `VACUUM` in a `post-hook`, however this cannot be executed within a transaction ([Redshift docs](https://docs.aws.amazon.com/redshift/latest/dg/r_VACUUM_command.html#r_VACUUM_usage_notes))
-* You want to insert a record into an audit <Term id="table" /> at the start of a run, and do not want that statement rolled back if the model creation fails.
+* You want to run a `VACUUM` in a `post-hook`, however, this cannot be executed within a transaction ([Redshift docs](https://docs.aws.amazon.com/redshift/latest/dg/r_VACUUM_command.html#r_VACUUM_usage_notes))
+* You want to insert a record into an audit <Term id="table" /> at the start of a run and do not want that statement rolled back if the model creation fails.
 
-To achieve this, you can use one of the following syntaxes. (Note: You should NOT use this syntax if using a database where dbt does not use transactions by default, including Snowflake, BigQuery, and Spark/Databricks.)
+To achieve this behavior, you can use one of the following syntaxes:
+  - Important note: Do not use this syntax if you are using a database where dbt does not support transactions. This includes databases like Snowflake, BigQuery, and Spark or Databricks.
+
+<Tabs>
+<TabItem value="beforebegin" label="Use before_begin and after_commit">
 
 #### Config block: use the `before_begin` and `after_commit` helper macros
 
@@ -200,6 +204,9 @@ select ...
 ```
 
 </File>
+</TabItem>
+
+<TabItem value="dictionary" label="Use a dictionary">
 
 #### Config block: use a dictionary
 <File name='models/<modelname>.sql'>
@@ -224,6 +231,10 @@ select ...
 
 </File>
 
+</TabItem>
+
+<TabItem value="dbt_project.yml" label="Use dbt_project.yml">
+
 #### `dbt_project.yml`: Use a dictionary
 
 <File name='dbt_project.yml'>
@@ -242,3 +253,5 @@ models:
 ```
 
 </File>
+</TabItem>
+</Tabs>