This PR will result in the following new package version:
1.3.0 as this is very breaking for the 2 customers still using basic SQL transformations (and anyone looking at the stale tables for historical analyses)
Please detail what change(s) this PR introduces and any additional information that should be known during the review of this PR:
This PR removes the transformation and trigger_table sources, staging models, variables, documentation, and downstream transforms (essentially the entire fivetran_platform__transformation_status end model)
It does NOT remove transformation_id and transformation-oriented logic from the staing log model. I chose not to remove this for 2 reasons:
the log table is historical, so if someone had basic SQL transformations in the past they will have transformation records in LOG. We should continue to correctly label these
i believe the product team intends to rollout a new dbt-transformation version of the transformation and trigger_table tables next year, so log.transformation_id could become relevant again (and isn't causing trouble)
PR Checklist
Basic Validation
Please acknowledge that you have successfully performed the following commands locally:
[x] dbt compile
[x] dbt run –full-refresh
[x] dbt run
[ ] dbt test -- getting a uniqueness failure in the audit_table on incremental runs... that's unrelated (on main 😓) but looking into it....
[x] dbt run –vars (if applicable)
Before marking this PR as "ready for review" the following have been applied:
[x] The appropriate issue has been linked and tagged
[x] You are assigned to the corresponding issue and this PR
[x] BuildKite integration tests are passing
Detailed Validation
Please acknowledge that the following validation checks have been performed prior to marking this PR as "ready for review":
[x] You have validated these changes and assure this PR will address the respective Issue/Feature.
[x] You are reasonably confident these changes will not impact any other components of this package or any dependent packages.
[x] You have provided details below around the validation steps performed to gain confidence in these changes.
See the Hex notebook (in height ticket) for my sanity check validations, but truthfully the validation for this task is largely non-sql. Transformations and triggers were only involved in the now-deprecated transformation_status end model. No other end models depend on these sources.
So outside of SQL and into the CLI...
On main, if you do not have fivetran_platform_using_transformations and fivetran_platform_using_triggers set to False and you don't have the transformation and trigger_table, a dbt run would result in
One must set these variables to False explicitly (they are true by default) for a successful run
Thus, this PR makes so it that we achieve the above image without having users (who almost certainly don't have these tables and/or don't want to transform stale data) set any variables.
So if i comment these back out
And dbt run, everything works out
Standard Updates
Please acknowledge that your PR contains the following standard updates:
Package versioning has been appropriately indexed in the following locations:
[x] indexed within dbt_project.yml
[x] indexed within integration_tests/dbt_project.yml
[x] CHANGELOG has individual entries for each respective change in this PR
[x] README updates have been applied (if applicable)
[ ] DECISIONLOG updates have been updated (if applicable)
[x] Appropriate yml documentation has been added (if applicable)
dbt Docs
Please acknowledge that after the above were all completed the below were applied to your branch:
[ ] docs were regenerated (unless this PR does not include any code or yml updates) -- waiting to do so on release branch
If you had to summarize this PR in an emoji, which would it be?
PR Overview
This PR will address the following Issue/Feature: https://github.com/fivetran/dbt_fivetran_log/issues/93
This PR will result in the following new package version:
1.3.0 as this is very breaking for the 2 customers still using basic SQL transformations (and anyone looking at the stale tables for historical analyses)
Please detail what change(s) this PR introduces and any additional information that should be known during the review of this PR:
This PR removes the
transformationandtrigger_tablesources, staging models, variables, documentation, and downstream transforms (essentially the entirefivetran_platform__transformation_statusend model)It does NOT remove
transformation_idand transformation-oriented logic from the staing log model. I chose not to remove this for 2 reasons:LOG. We should continue to correctly label thesetransformationandtrigger_tabletables next year, solog.transformation_idcould become relevant again (and isn't causing trouble)PR Checklist
Basic Validation
Please acknowledge that you have successfully performed the following commands locally:
Before marking this PR as "ready for review" the following have been applied:
Detailed Validation
Please acknowledge that the following validation checks have been performed prior to marking this PR as "ready for review":
See the Hex notebook (in height ticket) for my sanity check validations, but truthfully the validation for this task is largely non-sql. Transformations and triggers were only involved in the now-deprecated
transformation_statusend model. No other end models depend on these sources.So outside of SQL and into the CLI...
On main, if you do not have
fivetran_platform_using_transformationsandfivetran_platform_using_triggersset toFalseand you don't have the transformation and trigger_table, adbt runwould result inOne must set these variables to False explicitly (they are true by default) for a successful run
Thus, this PR makes so it that we achieve the above image without having users (who almost certainly don't have these tables and/or don't want to transform stale data) set any variables.
So if i comment these back out
And dbt run, everything works out
Standard Updates
Please acknowledge that your PR contains the following standard updates:
dbt Docs
Please acknowledge that after the above were all completed the below were applied to your branch:
If you had to summarize this PR in an emoji, which would it be?
🥶