-
Notifications
You must be signed in to change notification settings - Fork 960
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
New best practice guide for clone #4542
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
Co-authored-by: mirnawong1 <[email protected]>
Co-authored-by: mirnawong1 <[email protected]>
Co-authored-by: mirnawong1 <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm !
|
||
This can be suboptimal because: | ||
- Typically incremental models are your largest datasets, so they take a long time to build in their entirety which can slow down development time and incur high warehouse costs. | ||
- There are situations where a `full-refresh` of the incremental model passes successfully in your CI job but an _incremental_ build of that same table in prod would fail when the PR is merged into main (think schema drift where [on_schema_change](/docs/building-a-dbt-project/building-models/configuring-incremental-models#what-if-the-columns-of-my-incremental-model-change) config is set to `fail`) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- There are situations where a `full-refresh` of the incremental model passes successfully in your CI job but an _incremental_ build of that same table in prod would fail when the PR is merged into main (think schema drift where [on_schema_change](/docs/building-a-dbt-project/building-models/configuring-incremental-models#what-if-the-columns-of-my-incremental-model-change) config is set to `fail`) | |
- There are situations where a `full-refresh` of the incremental model passes successfully in your CI job but an _incremental_ build of that same table in prod would fail when the PR is merged into main (think schema drift where [on_schema_change](/docs/build/incremental-models#understanding-the-is_incremental-macro) config is set to `fail`) |
Co-authored-by: mirnawong1 <[email protected]>
Co-authored-by: mirnawong1 <[email protected]>
Co-authored-by: mirnawong1 <[email protected]>
|
||
**Relevant `dbt clone` Slack thread:** https://dbt-labs.slack.com/archives/C05FWBP9X1U/p1692830261651829 | ||
|
||
### From the "Better CI for better data quality" coalesce talk |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we feel like this chunk adds any value? If it's just repetitive, happy to cut it!
|
||
## Additional help | ||
|
||
**Relevant `dbt clone` Slack thread:** https://dbt-labs.slack.com/archives/C05FWBP9X1U/p1692830261651829 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is an internal slack thread and would not be relevant to readers, this was just on the issue to add more color to what content we should include - we should cut this
What are you changing in this pull request and why?
Closes issue #4359
Checklist
Adding new pages (delete if not applicable):
website/sidebars.js