Update to version 2.0

[sanjay-kv]

Upgrading to v1.8 (latest) Ref #480 Closes: #464
Resources
Changelog
dbt Core CLI Installation guide
Cloud upgrade guide
What to know before upgrading
dbt Labs is committed to providing backward compatibility for all versions 1.x, except for any changes explicitly mentioned on this page. If you encounter an error upon upgrading, please let us know by opening an issue.

Versionless
dbt Cloud is going "versionless." This means you'll automatically get early access to new features and functionality before they're available in final releases of dbt Core.

Select Versionless in your development, staging, and production environments to access to everything in dbt Core v1.8+ and more.

To upgrade an environment in the dbt Cloud Admin API or Terraform, set dbt_version to the string versionless.

Caution

Do not run in production until after migration

gitGraph:
    commit "Ashish"
    branch newbranch
    checkout newbranch
    commit id:"1111"
    commit tag:"test"
    checkout main
    commit type: HIGHLIGHT
    commit
    merge newbranch
    commit
    branch b2
    commit

Loading

New and changed features and functionality
Features and functionality new in dbt v1.8.

New dbt Core adapter installation procedure
Before dbt Core v1.8, whenever you would pip install a data warehouse adapter for dbt, pip would automatically install dbt-core alongside it. The dbt adapter directly depended on components of dbt-core, and dbt-core depended on the adapter for execution. This bidirectional dependency made it difficult to develop adapters independent of dbt-core.

Beginning in v1.8, dbt-core and adapters are decoupled. Going forward, your installations should explicitly include both dbt-core and the desired adapter. The new pip installation command should look like this:

pip install dbt-core dbt-ADAPTER_NAME

For example, you would use the following command if you use Snowflake:

pip install dbt-core dbt-snowflake

For the time being, we have maintained install-time dependencies to avoid breaking existing scripts in surprising ways; pip install dbt-snowflake will continue to install the latest versions of both dbt-core and dbt-snowflake. Given that we may remove this implicit dependency in future versions, we strongly encourage you to update install scripts now.

Unit Tests
Historically, dbt's test coverage was confined to “data” tests, assessing the quality of input data or resulting datasets' structure.

In v1.8, we're introducing native support for unit testing. 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 method to run only unit or data tests:

dbt test --select "test_type:unit"           # run all unit tests
dbt test --select "test_type:data"           # run all data tests

Unit tests are defined in YML files in your models/ directory and are currently only supported on SQL models. To distinguish between the two, the tests: config has been renamed to data_tests:. Both are currently supported for backward compatibility.

New data_tests: syntax
The tests: syntax is changing to reflect the addition of unit tests. Start migrating your data test YML to use data_tests: after you upgrade to v1.8 to prevent issues in the future.

models:
  - name: orders
    columns:
      - name: order_id
        data_tests:
          - unique
          - not_null

The --empty flag
The run and build 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.