-
Notifications
You must be signed in to change notification settings - Fork 27
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
bug/renamed-columns #55
Conversation
packages.yml
Outdated
# - package: fivetran/salesforce_source | ||
# version: [">=1.1.0", "<1.2.0"] | ||
- git: https://github.com/fivetran/dbt_salesforce_source.git | ||
revision: bug/renamed-columns-option3 | ||
warn-unpinned: false |
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.
# - package: fivetran/salesforce_source | |
# version: [">=1.1.0", "<1.2.0"] | |
- git: https://github.com/fivetran/dbt_salesforce_source.git | |
revision: bug/renamed-columns-option3 | |
warn-unpinned: false | |
- package: fivetran/salesforce_source | |
version: [">=1.1.0", "<1.2.0"] |
commit before merge
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.
@fivetran-catfritz thanks for applying this breaking change update here and also adding the validation test! A have a few small comments and one small thing I wanted to callout, I noticed the consistency_daily_activity
test for me is failing when using our internal data 🤔
Would you be able to look into this and see if you also experience these row failures? At first glance it looks like the only field are not tying out between dev and prod is the following:
- tasks_completed
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.
Thanks for creating this here as well!
case when lower(data_type) like '%numeric%' or lower(data_type) like '%float%' then 'numeric' | ||
else data_type | ||
end as data_type |
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.
Now that we are making this a breaking change, would it make more sense to remove this case when statement? We know it will fail for this release (why it is breaking now), but it should not need this case statement for future updates and could risk us not catching datatype mismatches.
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.
Yeah it was helpful to run it this time with the case statement but it makes sense to remove it for the future. Updated!
final as ( | ||
-- test will fail if any rows from prod are not found in dev | ||
(select * from prod | ||
except distinct | ||
select * from dev) | ||
|
||
union all -- union since we only care if rows are produced | ||
|
||
-- test will fail if any rows from dev are not found in prod | ||
(select * from dev | ||
except distinct | ||
select * from prod) | ||
) |
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 test is great! However, if there is a failure it is really difficult to decipher. Which record is from the prod/dev test and which is from the dev/prod test. Would there be a way to make this easier to understand when there is a failure?
Not required in this update, but I know we are reusing this a lot and would like to think about this for a future enhancement.
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.
Good point. I found a way and updated!
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.
@fivetran-joemarkiewicz I have made the update here as well!
Adding a note here about the consistency test failure for consistency_daily_activity
. I added a filter to remove the current day's rows in case there is sync activity for the current day between prod and dev runs. There is still the chance of a failure if other changes happen in between runs, but removing the current day should reduce that chance.
case when lower(data_type) like '%numeric%' or lower(data_type) like '%float%' then 'numeric' | ||
else data_type | ||
end as data_type |
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.
Yeah it was helpful to run it this time with the case statement but it makes sense to remove it for the future. Updated!
final as ( | ||
-- test will fail if any rows from prod are not found in dev | ||
(select * from prod | ||
except distinct | ||
select * from dev) | ||
|
||
union all -- union since we only care if rows are produced | ||
|
||
-- test will fail if any rows from dev are not found in prod | ||
(select * from dev | ||
except distinct | ||
select * from prod) | ||
) |
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.
Good point. I found a way and updated!
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 once the package dep is bumped
- Specifically, the package now performs a COALESCE, preferring the original Salesforce API naming. If the original naming is not present, the Fivetran version is used instead. | ||
- Renamed columns are now explicitly cast to prevent conflicts during the COALESCE. | ||
- ❗This change is considered breaking since the resulting column types may differ from prior versions of this package. | ||
|
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.
Would recommend adding a Under the Hood section, and a line for the consistency tests you created.
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.
@fivetran-catfritz Ready for release on Monday, with two minor edits on the CHANGELOG!
Co-authored-by: Avinash Kunnath <[email protected]>
PR Overview
This PR will address the following Issue/Feature:
This PR will result in the following new package version:
Please provide the finalized CHANGELOG entry which details the relevant changes included in this PR:
PR Checklist
Basic Validation
Please acknowledge that you have successfully performed the following commands locally:
dbt run (if incremental models are present) && dbt testBefore marking this PR as "ready for review" the following have been applied:
Detailed Validation
Please share any and all of your validation steps:
If you had to summarize this PR in an emoji, which would it be?
💃