diff --git a/website/docs/reference/resource-configs/bigquery-configs.md b/website/docs/reference/resource-configs/bigquery-configs.md
index ffbaa37c059..d3497a02caf 100644
--- a/website/docs/reference/resource-configs/bigquery-configs.md
+++ b/website/docs/reference/resource-configs/bigquery-configs.md
@@ -718,3 +718,188 @@ Views with this configuration will be able to select from objects in `project_1.
The `grant_access_to` config is not thread-safe when multiple views need to be authorized for the same dataset. The initial `dbt run` operation after a new `grant_access_to` config is added should therefore be executed in a single thread. Subsequent runs using the same configuration will not attempt to re-apply existing access grants, and can make use of multiple threads.
+
+
+## Materialized views
+
+The BigQuery adapter supports [materialized views](https://cloud.google.com/bigquery/docs/materialized-views-intro)
+with the following configuration parameters:
+
+| Parameter | Type | Required | Default | Change Monitoring Support |
+|-------------------------------------------------------------|------------------------|----------|---------|---------------------------|
+| `on_configuration_change` | `` | no | `apply` | n/a |
+| [`cluster_by`](#clustering-clause) | `[]` | no | `none` | drop/create |
+| [`partition_by`](#partition-clause) | `{}` | no | `none` | drop/create |
+| [`enable_refresh`](#auto-refresh) | `` | no | `true` | alter |
+| [`refresh_interval_minutes`](#auto-refresh) | `` | no | `30` | alter |
+| [`max_staleness`](#auto-refresh) (in Preview) | `` | no | `none` | alter |
+| [`description`](/reference/resource-properties/description) | `` | no | `none` | alter |
+| [`labels`](#specifying-labels) | `{: }` | no | `none` | alter |
+| [`hours_to_expiration`](#controlling-table-expiration) | `` | no | `none` | alter |
+| [`kms_key_name`](#using-kms-encryption) | `` | no | `none` | alter |
+
+
+
+
+
+
+
+
+```yaml
+models:
+ [](/reference/resource-configs/resource-path):
+ [+](/reference/resource-configs/plus-prefix)[materialized](/reference/resource-configs/materialized): materialized_view
+ [+](/reference/resource-configs/plus-prefix)on_configuration_change: apply | continue | fail
+ [+](/reference/resource-configs/plus-prefix)[cluster_by](#clustering-clause): | []
+ [+](/reference/resource-configs/plus-prefix)[partition_by](#partition-clause):
+ - field:
+ - data_type: timestamp | date | datetime | int64
+ # only if `data_type` is not 'int64'
+ - granularity: hour | day | month | year
+ # only if `data_type` is 'int64'
+ - range:
+ - start:
+ - end:
+ - interval:
+ [+](/reference/resource-configs/plus-prefix)[enable_refresh](#auto-refresh): true | false
+ [+](/reference/resource-configs/plus-prefix)[refresh_interval_minutes](#auto-refresh):
+ [+](/reference/resource-configs/plus-prefix)[max_staleness](#auto-refresh):
+ [+](/reference/resource-configs/plus-prefix)[description](/reference/resource-properties/description):
+ [+](/reference/resource-configs/plus-prefix)[labels](#specifying-labels): {: }
+ [+](/reference/resource-configs/plus-prefix)[hours_to_expiration](#acontrolling-table-expiration):
+ [+](/reference/resource-configs/plus-prefix)[kms_key_name](##using-kms-encryption):
+```
+
+
+
+
+
+
+
+
+
+
+```yaml
+version: 2
+
+models:
+ - name: []
+ config:
+ [materialized](/reference/resource-configs/materialized): materialized_view
+ on_configuration_change: apply | continue | fail
+ [cluster_by](#clustering-clause): | []
+ [partition_by](#partition-clause):
+ - field:
+ - data_type: timestamp | date | datetime | int64
+ # only if `data_type` is not 'int64'
+ - granularity: hour | day | month | year
+ # only if `data_type` is 'int64'
+ - range:
+ - start:
+ - end:
+ - interval:
+ [enable_refresh](#auto-refresh): true | false
+ [refresh_interval_minutes](#auto-refresh):
+ [max_staleness](#auto-refresh):
+ [description](/reference/resource-properties/description):
+ [labels](#specifying-labels): {: }
+ [hours_to_expiration](#acontrolling-table-expiration):
+ [kms_key_name](##using-kms-encryption):
+```
+
+
+
+
+
+
+
+
+
+
+```jinja
+{{ config(
+ [materialized](/reference/resource-configs/materialized)='materialized_view',
+ on_configuration_change="apply" | "continue" | "fail",
+ [cluster_by](#clustering-clause)="" | [""],
+ [partition_by](#partition-clause)={
+ "field": "",
+ "data_type": "timestamp" | "date" | "datetime" | "int64",
+
+ # only if `data_type` is not 'int64'
+ "granularity": "hour" | "day" | "month" | "year,
+
+ # only if `data_type` is 'int64'
+ "range": {
+ "start": ,
+ "end": ,
+ "interval": ,
+ }
+ },
+
+ # auto-refresh options
+ [enable_refresh](#auto-refresh)= true | false,
+ [refresh_interval_minutes](#auto-refresh)=,
+ [max_staleness](#auto-refresh)="",
+
+ # additional options
+ [description](/reference/resource-properties/description)="",
+ [labels](#specifying-labels)={
+ "": "",
+ },
+ [hours_to_expiration](#acontrolling-table-expiration)=,
+ [kms_key_name](##using-kms-encryption)="",
+) }}
+```
+
+
+
+
+
+
+
+Many of these parameters correspond to their table counterparts and have been linked above.
+The set of parameters unique to materialized views covers [auto-refresh functionality](#auto-refresh).
+
+Find more information about these parameters in the BigQuery docs:
+- [CREATE MATERIALIZED VIEW statement](https://cloud.google.com/bigquery/docs/reference/standard-sql/data-definition-language#create_materialized_view_statement)
+- [materialized_view_option_list](https://cloud.google.com/bigquery/docs/reference/standard-sql/data-definition-language#materialized_view_option_list)
+
+### Auto-refresh
+
+| Parameter | Type | Required | Default | Change Monitoring Support |
+|------------------------------|--------------|----------|---------|---------------------------|
+| `enable_refresh` | `` | no | `true` | alter |
+| `refresh_interval_minutes` | `` | no | `30` | alter |
+| `max_staleness` (in Preview) | `` | no | `none` | alter |
+
+BigQuery supports [automatic refresh](https://cloud.google.com/bigquery/docs/materialized-views-manage#automatic_refresh) configuration for materialized views.
+By default, a materialized view will automatically refresh within 5 minutes of changes in the base table, but not more frequently than once every 30 minutes.
+BigQuery only officially supports the configuration of the frequency (the "once every 30 minutes" frequency);
+however, there is a feature in preview that allows for the configuration of the staleness (the "5 minutes" refresh).
+dbt will monitor these parameters for changes and apply them using an `ALTER` statement.
+
+Find more information about these parameters in the BigQuery docs:
+- [materialized_view_option_list](https://cloud.google.com/bigquery/docs/reference/standard-sql/data-definition-language#materialized_view_option_list)
+- [max_staleness](https://cloud.google.com/bigquery/docs/materialized-views-create#max_staleness)
+
+### Limitations
+
+As with most data platforms, there are limitations associated with materialized views. Some worth noting include:
+
+- Materialized view SQL has a [limited feature set](https://cloud.google.com/bigquery/docs/materialized-views-create#supported-mvs).
+- Materialized view SQL cannot be updated; the materialized view must go through a `--full-refresh` (DROP/CREATE).
+- The `partition_by` clause on a materialized view must match that of the underlying base table.
+- While materialized views can have descriptions, materialized view *columns* cannot.
+- Recreating/dropping the base table requires recreating/dropping the materialized view.
+
+Find more information about materialized view limitations in Google's BigQuery [docs](https://cloud.google.com/bigquery/docs/materialized-views-intro#limitations).
+
+
diff --git a/website/docs/reference/resource-configs/postgres-configs.md b/website/docs/reference/resource-configs/postgres-configs.md
index 97a695ee12e..8465a5cbb31 100644
--- a/website/docs/reference/resource-configs/postgres-configs.md
+++ b/website/docs/reference/resource-configs/postgres-configs.md
@@ -108,21 +108,100 @@ models:
## Materialized views
-The Postgres adapter supports [materialized views](https://www.postgresql.org/docs/current/rules-materializedviews.html).
-Indexes are the only configuration that is specific to `dbt-postgres`.
-The remaining configuration follows the general [materialized view](/docs/build/materializations#materialized-view) configuration.
-There are also some limitations that we hope to address in the next version.
+The Postgres adapter supports [materialized views](https://www.postgresql.org/docs/current/rules-materializedviews.html)
+with the following configuration parameters:
-### Monitored configuration changes
+| Parameter | Type | Required | Default | Change Monitoring Support |
+|---------------------------|--------------------|----------|---------|---------------------------|
+| `on_configuration_change` | `` | no | `apply` | n/a |
+| [`indexes`](#indexes) | `[{}]` | no | `none` | alter |
-The settings below are monitored for changes applicable to `on_configuration_change`.
+
-#### Indexes
-Index changes (`CREATE`, `DROP`) can be applied without the need to rebuild the materialized view.
-This differs from a table model, where the table needs to be dropped and re-created to update the indexes.
-If the `indexes` portion of the `config` block is updated, the changes will be detected and applied
-directly to the materialized view in place.
+
+
+
+
+```yaml
+models:
+ [](/reference/resource-configs/resource-path):
+ [+](/reference/resource-configs/plus-prefix)[materialized](/reference/resource-configs/materialized): materialized_view
+ [+](/reference/resource-configs/plus-prefix)on_configuration_change: apply | continue | fail
+ [+](/reference/resource-configs/plus-prefix)[indexes](#indexes):
+ - columns: []
+ unique: true | false
+ type: hash | btree
+```
+
+
+
+
+
+
+
+
+
+
+```yaml
+version: 2
+
+models:
+ - name: []
+ config:
+ [materialized](/reference/resource-configs/materialized): materialized_view
+ on_configuration_change: apply | continue | fail
+ [indexes](#indexes):
+ - columns: []
+ unique: true | false
+ type: hash | btree
+```
+
+
+
+
+
+
+
+
+
+
+```jinja
+{{ config(
+ [materialized](/reference/resource-configs/materialized)="materialized_view",
+ on_configuration_change="apply" | "continue" | "fail",
+ [indexes](#indexes)=[
+ {
+ "columns": [""],
+ "unique": true | false,
+ "type": "hash" | "btree",
+ }
+ ]
+) }}
+```
+
+
+
+
+
+
+
+The [`indexes`](#indexes) parameter corresponds to that of a table, as explained above.
+It's worth noting that, unlike tables, dbt monitors this parameter for changes and applies the changes without dropping the materialized view.
+This happens via a `DROP/CREATE` of the indexes, which can be thought of as an `ALTER` of the materialized view.
+
+Find more information about materialized view parameters in the Postgres docs:
+- [CREATE MATERIALIZED VIEW](https://www.postgresql.org/docs/current/sql-creatematerializedview.html)
+
+
### Limitations
@@ -138,3 +217,5 @@ If the user changes the model's config to `materialized="materialized_view"`, th
The solution is to execute `DROP TABLE my_model` on the data warehouse before trying the model again.
+
+
diff --git a/website/docs/reference/resource-configs/redshift-configs.md b/website/docs/reference/resource-configs/redshift-configs.md
index 9bd127a1e1a..b559c0451b0 100644
--- a/website/docs/reference/resource-configs/redshift-configs.md
+++ b/website/docs/reference/resource-configs/redshift-configs.md
@@ -111,40 +111,138 @@ models:
## Materialized views
-The Redshift adapter supports [materialized views](https://docs.aws.amazon.com/redshift/latest/dg/materialized-view-overview.html).
-Redshift-specific configuration includes the typical `dist`, `sort_type`, `sort`, and `backup`.
-For materialized views, there is also the `auto_refresh` setting, which allows Redshift to [automatically refresh](https://docs.aws.amazon.com/redshift/latest/dg/materialized-view-refresh.html) the materialized view for you.
-The remaining configuration follows the general [materialized view](/docs/build/materializations#Materialized-View) configuration.
-There are also some limitations that we hope to address in the next version.
+The Redshift adapter supports [materialized views](https://docs.aws.amazon.com/redshift/latest/dg/materialized-view-overview.html)
+with the following configuration parameters:
+
+| Parameter | Type | Required | Default | Change Monitoring Support |
+|-------------------------------------------|--------------|----------|------------------------------------------------|---------------------------|
+| `on_configuration_change` | `` | no | `apply` | n/a |
+| [`dist`](#using-sortkey-and-distkey) | `` | no | `even` | drop/create |
+| [`sort`](#using-sortkey-and-distkey) | `[]` | no | `none` | drop/create |
+| [`sort_type`](#using-sortkey-and-distkey) | `` | no | `auto` if no `sort`
`compound` if `sort` | drop/create |
+| [`auto_refresh`](#auto-refresh) | `` | no | `false` | alter |
+| [`backup`](#backup) | `` | no | `true` | n/a |
+
+
+
+
+
+
+
+
+```yaml
+models:
+ [](/reference/resource-configs/resource-path):
+ [+](/reference/resource-configs/plus-prefix)[materialized](/reference/resource-configs/materialized): materialized_view
+ [+](/reference/resource-configs/plus-prefix)on_configuration_change: apply | continue | fail
+ [+](/reference/resource-configs/plus-prefix)[dist](#using-sortkey-and-distkey): all | auto | even |
+ [+](/reference/resource-configs/plus-prefix)[sort](#using-sortkey-and-distkey): | []
+ [+](/reference/resource-configs/plus-prefix)[sort_type](#using-sortkey-and-distkey): auto | compound | interleaved
+ [+](/reference/resource-configs/plus-prefix)[auto_refresh](#auto-refresh): true | false
+ [+](/reference/resource-configs/plus-prefix)[backup](#backup): true | false
+```
+
+
+
+
-### Monitored configuration changes
-The settings below are monitored for changes applicable to `on_configuration_change`.
+
-#### Dist
+
-Changes to `dist` will result in a full refresh of the existing materialized view (applied at the time of the next `dbt run` of the model). Redshift requires a materialized view to be
-dropped and recreated to apply a change to the `distkey` or `diststyle`.
+```yaml
+version: 2
-#### Sort type, sort
+models:
+ - name: []
+ config:
+ [materialized](/reference/resource-configs/materialized): materialized_view
+ on_configuration_change: apply | continue | fail
+ [dist](#using-sortkey-and-distkey): all | auto | even |
+ [sort](#using-sortkey-and-distkey): | []
+ [sort_type](#using-sortkey-and-distkey): auto | compound | interleaved
+ [auto_refresh](#auto-refresh): true | false
+ [backup](#backup): true | false
+```
+
+
-Changes to `sort_type` or `sort` will result in a full refresh. Redshift requires a materialized
-view to be dropped and recreated to apply a change to the `sortkey` or `sortstyle`.
+
+
+
+
+
+
+
+```jinja
+{{ config(
+ [materialized](/reference/resource-configs/materialized)="materialized_view",
+ on_configuration_change="apply" | "continue" | "fail",
+ [dist](#using-sortkey-and-distkey)="all" | "auto" | "even" | "",
+ [sort](#using-sortkey-and-distkey)=[""],
+ [sort_type](#using-sortkey-and-distkey)="auto" | "compound" | "interleaved",
+ [auto_refresh](#auto-refresh)=true | false,
+ [backup](#backup)=true | false,
+) }}
+```
+
+
+
+
+
+
+
+Many of these parameters correspond to their table counterparts and have been linked above.
+The parameters unique to materialized views are the [auto-refresh](#auto-refresh) and [backup](#backup) functionality, which are covered below.
+
+Find more information about the [CREATE MATERIALIZED VIEW](https://docs.aws.amazon.com/redshift/latest/dg/materialized-view-create-sql-command.html) parameters in the Redshift docs.
+
+#### Auto-refresh
+
+| Parameter | Type | Required | Default | Change Monitoring Support |
+|----------------|-------------|----------|---------|---------------------------|
+| `auto_refresh` | `` | no | `false` | alter |
+
+Redshift supports [automatic refresh](https://docs.aws.amazon.com/redshift/latest/dg/materialized-view-refresh.html#materialized-view-auto-refresh) configuration for materialized views.
+By default, a materialized view does not automatically refresh.
+dbt monitors this parameter for changes and applies them using an `ALTER` statement.
+
+Learn more information about the [parameters](https://docs.aws.amazon.com/redshift/latest/dg/materialized-view-create-sql-command.html#mv_CREATE_MATERIALIZED_VIEW-parameters) in the Redshift docs.
#### Backup
-Changes to `backup` will result in a full refresh. Redshift requires a materialized
-view to be dropped and recreated to apply a change to the `backup` setting.
+| Parameter | Type | Required | Default | Change Monitoring Support |
+|-----------|-------------|----------|---------|---------------------------|
+| `backup` | `` | no | `true` | n/a |
-#### Auto refresh
+Redshift supports [backup](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-snapshots.html) configuration of clusters at the object level.
+This parameter identifies if the materialized view should be backed up as part of the cluster snapshot.
+By default, a materialized view will be backed up during a cluster snapshot.
+dbt cannot monitor this parameter as it is not queryable within Redshift.
+If the value is changed, the materialized view will need to go through a `--full-refresh` in order to set it.
-The `auto_refresh` setting can be updated via an `ALTER` statement. This setting effectively toggles
-automatic refreshes on or off. The default setting for this config is off (`False`). If this
-is the only configuration change for the materialized view, dbt will choose to apply
-an `ALTER` statement instead of issuing a full refresh,
+Learn more about the [parameters](https://docs.aws.amazon.com/redshift/latest/dg/materialized-view-create-sql-command.html#mv_CREATE_MATERIALIZED_VIEW-parameters) in the Redshift docs.
### Limitations
+As with most data platforms, there are limitations associated with materialized views. Some worth noting include:
+
+- Materialized views cannot reference views, temporary tables, user-defined functions, or late-binding tables.
+- Auto-refresh cannot be used if the materialized view references mutable functions, external schemas, or another materialized view.
+
+Find more information about materialized view limitations in Redshift's [docs](https://docs.aws.amazon.com/redshift/latest/dg/materialized-view-create-sql-command.html#mv_CREATE_MATERIALIZED_VIEW-limitations).
+
+
+
#### Changing materialization from "materialized_view" to "table" or "view"
Swapping a materialized view to a table or view is not supported.
@@ -157,3 +255,5 @@ If the user changes the model's config to `materialized="table"`, they will get
The workaround is to execute `DROP MATERIALIZED VIEW my_mv CASCADE` on the data warehouse before trying the model again.
+
+
diff --git a/website/docs/reference/resource-configs/snowflake-configs.md b/website/docs/reference/resource-configs/snowflake-configs.md
index 30c7966ec68..aa2bf370df6 100644
--- a/website/docs/reference/resource-configs/snowflake-configs.md
+++ b/website/docs/reference/resource-configs/snowflake-configs.md
@@ -346,82 +346,122 @@ In the configuration format for the model SQL file:
## Dynamic tables
-The Snowflake adapter supports [dynamic tables](https://docs.snowflake.com/en/sql-reference/sql/create-dynamic-table).
+The Snowflake adapter supports [dynamic tables](https://docs.snowflake.com/en/user-guide/dynamic-tables-about).
This materialization is specific to Snowflake, which means that any model configuration that
would normally come along for the ride from `dbt-core` (e.g. as with a `view`) may not be available
for dynamic tables. This gap will decrease in future patches and versions.
While this materialization is specific to Snowflake, it very much follows the implementation
of [materialized views](/docs/build/materializations#Materialized-View).
In particular, dynamic tables have access to the `on_configuration_change` setting.
-There are also some limitations that we hope to address in the next version.
+Dynamic tables are supported with the following configuration parameters:
-### Parameters
+| Parameter | Type | Required | Default | Change Monitoring Support |
+|----------------------------------------------------------|------------|----------|---------|---------------------------|
+| `on_configuration_change` | `` | no | `apply` | n/a |
+| [`target_lag`](#target-lag) | `` | yes | | alter |
+| [`snowflake_warehouse`](#configuring-virtual-warehouses) | `` | yes | | alter |
-Dynamic tables in `dbt-snowflake` require the following parameters:
-- `target_lag`
-- `snowflake_warehouse`
-- `on_configuration_change`
+
-To learn more about each parameter and what values it can take, see
-the Snowflake docs page: [`CREATE DYNAMIC TABLE: Parameters`](https://docs.snowflake.com/en/sql-reference/sql/create-dynamic-table).
-### Usage
+
-You can create a dynamic table by editing _one_ of these files:
+
-- the SQL file for your model
-- the `dbt_project.yml` configuration file
+```yaml
+models:
+ [](/reference/resource-configs/resource-path):
+ [+](/reference/resource-configs/plus-prefix)[materialized](/reference/resource-configs/materialized): dynamic_table
+ [+](/reference/resource-configs/plus-prefix)on_configuration_change: apply | continue | fail
+ [+](/reference/resource-configs/plus-prefix)[target_lag](#target-lag): downstream |
+ [+](/reference/resource-configs/plus-prefix)[snowflake_warehouse](#configuring-virtual-warehouses):
+```
-The following examples create a dynamic table:
+
-
+
-```sql
-{{ config(
- materialized = 'dynamic_table',
- snowflake_warehouse = 'snowflake_warehouse',
- target_lag = '10 minutes',
-) }}
-```
-
+
-
+
```yaml
+version: 2
+
models:
- path:
- materialized: dynamic_table
- snowflake_warehouse: snowflake_warehouse
- target_lag: '10 minutes'
+ - name: []
+ config:
+ [materialized](/reference/resource-configs/materialized): dynamic_table
+ on_configuration_change: apply | continue | fail
+ [target_lag](#target-lag): downstream |
+ [snowflake_warehouse](#configuring-virtual-warehouses):
```
-### Monitored configuration changes
+
-The settings below are monitored for changes applicable to `on_configuration_change`.
-#### Target lag
+
-Changes to `target_lag` can be applied by running an `ALTER` statement. Refreshing is essentially
-always on for dynamic tables; this setting changes how frequently the dynamic table is updated.
+
-#### Warehouse
+```jinja
+{{ config(
+ [materialized](/reference/resource-configs/materialized)="dynamic_table",
+ on_configuration_change="apply" | "continue" | "fail",
+ [target_lag](#target-lag)="downstream" | " seconds | minutes | hours | days",
+ [snowflake_warehouse](#configuring-virtual-warehouses)="",
+) }}
+```
+
+
+
+
+
+
+
+Find more information about these parameters in Snowflake's [docs](https://docs.snowflake.com/en/sql-reference/sql/create-dynamic-table):
-Changes to `snowflake_warehouse` can be applied via an `ALTER` statement.
+### Target lag
+
+Snowflake allows two configuration scenarios for scheduling automatic refreshes:
+- **Time-based** — Provide a value of the form ` { seconds | minutes | hours | days }`. For example, if the dynamic table needs to be updated every 30 minutes, use `target_lag='30 minutes'`.
+- **Downstream** — Applicable when the dynamic table is referenced by other dynamic tables. In this scenario, `target_lag='downstream'` allows for refreshes to be controlled at the target, instead of at each layer.
+
+Find more information about `target_lag` in Snowflake's [docs](https://docs.snowflake.com/en/user-guide/dynamic-tables-refresh#understanding-target-lag).
### Limitations
+As with materialized views on most data platforms, there are limitations associated with dynamic tables. Some worth noting include:
+
+- Dynamic table SQL has a [limited feature set](https://docs.snowflake.com/en/user-guide/dynamic-tables-tasks-create#query-constructs-not-currently-supported-in-dynamic-tables).
+- Dynamic table SQL cannot be updated; the dynamic table must go through a `--full-refresh` (DROP/CREATE).
+- Dynamic tables cannot be downstream from: materialized views, external tables, streams.
+- Dynamic tables cannot reference a view that is downstream from another dynamic table.
+
+Find more information about dynamic table limitations in Snowflake's [docs](https://docs.snowflake.com/en/user-guide/dynamic-tables-tasks-create#dynamic-table-limitations-and-supported-functions).
+
+
+
#### Changing materialization to and from "dynamic_table"
-Swapping an already materialized model to be a dynamic table and vice versa.
-The workaround is manually dropping the existing materialization in the data warehouse prior to calling `dbt run`.
-Normally, re-running with the `--full-refresh` flag would resolve this, but not in this case.
-This would only need to be done once as the existing object would then be a dynamic table.
+Version `1.6.x` does not support altering the materialization from a non-dynamic table be a dynamic table and vice versa.
+Re-running with the `--full-refresh` does not resolve this either.
+The workaround is manually dropping the existing model in the warehouse prior to calling `dbt run`.
+This only needs to be done once for the conversion.
For example, assume for the example model below, `my_model`, has already been materialized to the underlying data platform via `dbt run`.
-If the user changes the model's config to `materialized="dynamic_table"`, they will get an error.
+If the model config is updated to `materialized="dynamic_table"`, dbt will return an error.
The workaround is to execute `DROP TABLE my_model` on the data warehouse before trying the model again.
@@ -429,7 +469,7 @@ The workaround is to execute `DROP TABLE my_model` on the data warehouse before
```yaml
{{ config(
- materialized="table" # or any model type eg view, incremental
+ materialized="table" # or any model type (e.g. view, incremental)
) }}
```
@@ -437,3 +477,5 @@ The workaround is to execute `DROP TABLE my_model` on the data warehouse before
+
+