Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deprecated functionality for v1.8 #5475

Merged
merged 3 commits into from
May 9, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -78,6 +78,20 @@ models:

The [`run`](/reference/commands/run#the-`--empty`-flag) and [`build`](/reference/commands/build#the---empty-flag) commands now support the `--empty` flag for building schema-only dry runs. The `--empty` flag limits the refs and sources to zero rows. dbt will still execute the model SQL against the target data warehouse but will avoid expensive reads of input data. This validates dependencies and ensures your models will build properly.

### Deprecated functionality

The ability for installed packages to override built-in materializations without explicit opt-in from the user is being deprecated.

- Overriding a built-in materialization from an installed package raises a deprecation warning.
- Using a custom materialization from an installed package does not raise a deprecation warning.
- Using a built-in materialization package override from the root project via a wrapping materialization is still supported. For example:

```sql
{% materialization view, default %}
{{ return(my_cool_package.materialization_view_default()) }}
{% endmaterialization %}
```

### Managing changes to legacy behaviors

dbt Core v1.8 has introduced flags for [managing changes to legacy behaviors](/reference/global-configs/legacy-behaviors). You may opt into recently introduced changes (disabled by default), or opt out of mature changes (enabled by default), by setting `True` / `False` values, respectively, for `flags` in `dbt_project.yml`.
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -30,6 +30,7 @@ This is a relatively small behavior change, but worth calling out in case you no

Beginning with v1.7, running [`dbt deps`](/reference/commands/deps) creates or updates the `package-lock.yml` file in the _project_root_ where `packages.yml` is recorded. The `package-lock.yml` file contains a record of all packages installed and, if subsequent `dbt deps` runs contain no updated packages in `dependencies.yml` or `packages.yml`, dbt-core installs from `package-lock.yml`.


## New and changed features and functionality

- [`dbt docs generate`](/reference/commands/cmd-docs) now supports `--select` to generate [catalog metadata](/reference/artifacts/catalog-json) for a subset of your project. Currently available for Snowflake and Postgres only, but other adapters are coming soon.
Expand Down Expand Up @@ -76,6 +77,20 @@ The run_results.json now includes three attributes related to the `applied` stat
- `compiled_code`: Rendered string of the code that was compiled (empty after parsing, but full string after compiling).
- `relation_name`: The fully-qualified name of the object that was (or will be) created/updated within the database.

### Deprecated functionality

The ability for installed packages to override built-in materializations without explicit opt-in from the user is being deprecated.

- Overriding a built-in materialization from an installed package raises a deprecation warning.
- Using a custom materialization from an installed package does not raise a deprecation warning.
- Using a built-in materialization package override from the root project via a wrapping materialization is still supported. For example:

```
{% materialization view, default %}
{{ return(my_cool_package.materialization_view_default()) }}
{% endmaterialization %}
```


### Quick hits

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -85,6 +85,20 @@ More consistency and flexibility around packages. Resources defined in a package
[**Project dependencies**](/docs/collaborate/govern/project-dependencies): Introduces `dependencies.yml` and dependent `projects` as a feature of dbt Cloud Enterprise. Allows enforcing model access (public vs. protected/private) across project/package boundaries. Enables cross-project `ref` of public models, without requiring the installation of upstream source code.
:::

### Deprecated functionality

The ability for installed packages to override built-in materializations without explicit opt-in from the user is being deprecated.

- Overriding a built-in materialization from an installed package raises a deprecation warning.
- Using a custom materialization from an installed package does not raise a deprecation warning.
- Using a built-in materialization package override from the root project via a wrapping materialization is still supported. For example:

```
{% materialization view, default %}
{{ return(my_cool_package.materialization_view_default()) }}
{% endmaterialization %}
```
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wonder if this "deprecation notice" is worth capturing in a snippet/partial/reusable

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's only going in the migration guides. When we actually deprecate it in 1.9 I'll see how extensive it is. Snippet might be a good call then.


### 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
Expand Down
Loading