-
Notifications
You must be signed in to change notification settings - Fork 25
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
fix: aggregate by month in fivetran_log__mar_table_history #74
fix: aggregate by month in fivetran_log__mar_table_history #74
Conversation
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.
@simon-stepper thank you so much for your quick notice of this bug and for investigating the issue at hand and proposing a solution. 🥇
Your changes look good on my end; however, I have a few small requests to update in order for other warehouses to be compatible before rolling out this in the next release. Let me know if you have any questions.
Additionally, when testing your changes I actually noticed that there may be occurrences within the fivetran_log__mar_destinaton_history
model where a table can exist across multiple schemas in a destination. This still causes the test to fail. As such, I was able to adjust the test to include schema_name
and that worked for my testing. I am curious if you encountered the same. Nevertheless, it is an addition to the next release we will want to incorporate. Here is a screenshot of the change I made locally.
Let me know if you have any questions. I really appreciate your attentiveness and hope to roll these changes out as soon as possible.
@fivetran-joemarkiewicz thanks for the quick review! Would be great when you can apply these changes to make it work across warehouses, I'm Snowflake only. We don't have a case where a table name is not unique per connector in our setup, so this didn't occur for me. But I can see that happening and would be a good addition to make the package more robust. Thanks! |
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.
Approving this PR with these changes in place. I will hold off merging this until we are able to get another customer to test on their end and validate the changes.
Thank you again for all your help @simon-stepper
Are you a current Fivetran customer?
Yes, Simon Stepper, Analytics Lead at Capdesk from Carta
What change(s) does this PR introduce?
Fixing a bug introduced in v0.7.1 and switching the
fivetran_log__mar_table_history
back to a monthly aggregation.Did you update the CHANGELOG?
Does this PR introduce a breaking change?
Only changing the model's granularity to what it was in v0.7.0
Did you update the dbt_project.yml files with the version upgrade (please leverage standard semantic versioning)? (In both your main project and integration_tests)
Is this PR in response to a previously created Bug or Feature Request
How did you test the PR changes?
Tested with our own dbt project on Snowflake
Select which warehouse(s) were used to test the PR
Provide an emoji that best describes your current mood
⛷️
Feedback
We are so excited you decided to contribute to the Fivetran community dbt package! We continue to work to improve the packages and would greatly appreciate your feedback on our existing dbt packages or what you'd like to see next.