Merge branch 'current' into store-failures-as

website/docs/guides/migration/versions/01-upgrading-to-v1.6.md

@@ -90,4 +90,5 @@ More consistency and flexibility around packages. Resources defined in a package
 - [`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
 - [`--defer-state`](/reference/node-selection/defer) enables more-granular control 
+- [`dbt ls`](/reference/commands/list) adds the Semantic model selection method to allow for `dbt ls -s "semantic_model:*"` and the ability to execute `dbt ls --resource-type semantic_model`.
 

website/docs/reference/commands/list.md

@@ -10,7 +10,7 @@ The `dbt ls` command lists resources in your dbt project. It accepts selector ar
 ### Usage
 ```
 dbt ls
-     [--resource-type {model,source,seed,snapshot,metric,test,exposure,analysis,default,all}]
+     [--resource-type {model,semantic_model,source,seed,snapshot,metric,test,exposure,analysis,default,all}]
      [--select SELECTION_ARG [SELECTION_ARG ...]]
      [--models SELECTOR [SELECTOR ...]]
      [--exclude SELECTOR [SELECTOR ...]]
@@ -93,6 +93,16 @@ $ dbt ls --select snowplow.* --output json --output-keys name resource_type desc
 
 </VersionBlock>
 
+<VersionBlock firstVersion="1.6">
+
+**Listing Semantic models**
+
+List all resources upstream of your orders semantic model:
+```
+dbt ls -s +semantic_model:orders
+```
+
+</VersionBlock>
 
 **Listing file paths**
 ```

website/docs/reference/node-selection/methods.md

@@ -352,3 +352,18 @@ dbt list --select version:none        # models that are *not* versioned
 ```
 
 </VersionBlock>
+
+### The "semantic_model" method
+<VersionBlock lastVersion="1.5">
+Supported in v1.6 or newer.
+</VersionBlock>
+<VersionBlock firstVersion="1.6">
+
+The `semantic_model` method selects [semantic models](/docs/build/semantic-models).
+
+```bash
+dbt list --select semantic_model:*        # list all semantic models 
+dbt list --select +semantic_model:orders  # list your semantic model named "orders" and all upstream resources
+```
+
+</VersionBlock>

website/docs/reference/resource-configs/contract.md

@@ -23,8 +23,31 @@ When the `contract` configuration is enforced, dbt will ensure that your model's
 
 This is to ensure that the people querying your model downstream—both inside and outside dbt—have a predictable and consistent set of columns to use in their analyses. Even a subtle change in data type, such as from `boolean` (`true`/`false`) to `integer` (`0`/`1`), could cause queries to fail in surprising ways.
 
+<VersionBlock lastVersion="1.6">
+
 The `data_type` defined in your YAML file must match a data type your data platform recognizes. dbt does not do any type aliasing itself. If your data platform recognizes both `int` and `integer` as corresponding to the same type, then they will return a match.
 
+</VersionBlock>
+
+<VersionBlock firstVersion="1.7">
+
+dbt uses built-in type aliasing for the `data_type` defined in your YAML. For example, you can specify `string` in your contract, and on Postgres/Redshift, dbt will convert it to `text`. If dbt doesn't recognize the `data_type` name among its known aliases, it will pass it through as-is. This is enabled by default, but you can opt-out by setting `alias_types` to `false`.
+
+Example for disabling: 
+
+```yml
+
+models:
+  - name: my_model
+    config:
+      contract:
+        enforced: true
+        alias_types: false  # true by default
+
+```
+
+</VersionBlock>
+
 When dbt compares data types, it will not compare granular details such as size, precision, or scale. We don't think you should sweat the difference between `varchar(256)` and `varchar(257)`, because it doesn't really affect the experience of downstream queriers. You can accomplish a more-precise assertion by [writing or using a custom test](/guides/best-practices/writing-custom-generic-tests).
 
 Note that you need to specify a varchar size or numeric scale, otherwise dbt relies on default values. For example, if a `numeric` type defaults to a precision of 38 and a scale of 0, then the numeric column stores 0 digits to the right of the decimal (it only stores whole numbers), which might cause it to fail contract enforcement. To avoid this implicit coercion, specify your `data_type` with a nonzero scale, like `numeric(38, 6)`. dbt Core 1.7 and higher provides a warning if you don't specify precision and scale when providing a numeric data type.