dbt-labs / dbt-labs/dbt

[Feature] Support streamlined snapshots when intention is only to mitigate against deletions in the source table

Open
#11,867 3 comments 0 reactions 0 assignees View on GitHub
engine:v1 snapshots status:triage type:feature
Dominant language
Rust
Stars
13.8k
Forks
2.6k
Avg merge
21h 31m
Merged PRs (30d)
56

Description

### Is this your first time submitting a feature request?

- [x] I have read the [expectations for open source contributors](https://docs.getdbt.com/docs/contributing/oss-expectations)
- [x] I have searched the existing issues, and I could not find an existing issue for this feature
- [x] I am requesting a straightforward extension of existing dbt functionality, rather than a Big Idea better suited to a discussion

### Describe the feature

We have many tables in our source systems that are append-only except that they are subject to deletion.
This leads to several snapshots where, theoretically, I'd like to set "check_cols = []", but that is understood idiomatically as "check every column for any change."

I'm proposing that dbt provide a third `strategy` in addition to `check` and `timestamp` that indicates no comparisons are needed because the source data is expected to be immutable apart from deletions.

This would make the intention of the snapshot clearer and reduce processing time by at least a small amount. (I recognize that the gain in processing time is likely small.)

### Describe alternatives you've considered

We are currently handling this situation by using a `strategy='check'` setting `check_cols = [x]`, where x is a component of the `unique_id` term.

### Who will this benefit?

Users with append-only source tables that are subject to deletion.

### Are you interested in contributing this feature?

_No response_

### Anything else?

_No response_

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.