-
Notifications
You must be signed in to change notification settings - Fork 7
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
feature/api-updates #33
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.
@fivetran-catfritz Thanks for working through these feature updates! Your updates looks great and appreciate the care and thought that went into updating the package to be in line with the connector updates.
I do have a few comments, suggestions, and questions before approving the PR. Let me know if you have any questions on my suggestions. Happy to chat in more detail if you would like!
models/stg_marketo__lead.sql
Outdated
email, | ||
first_name, | ||
last_name | ||
|
||
{{ fivetran_utils.fill_pass_through_columns('marketo__lead_passthrough_columns') }} |
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.
Is there a reason we opted for the passthrough columns here as opposed to just bringing all the fields in (like we had done previously)?
Thinking from the end users experience, it may be a great deal of work to go through these custom fields and manually add them to the passthrough variable. Especially if we automatically included all the fields in the previous version of the package.
I would actually suggest removing the passthrough variable for the lead
models. Instead I would recommend we use the dbt-utils.star
method as we had before, but we just exclude the new fields.
Let me know if you have any concerns with this approach or any questions on why we would remove the passthrough variable.
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 I better understand the benefit of the .star method that makes total sense. 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.
Thanks! However it seems we may have some new issues. I ran this locally with our production data and I am running into an error:
I think there are two issues coming from this update:
- We have a missing comma if there are fields that fit the star criteria, but then we have a trailing comma if there are no fields 🤔
- The cte is pulling from the macro results. Therefore, all of these fields that are included in the star macro are not included in the get_lead_columns macro. We will need to rework this staging model to account for these fields not included in the get_lead_columns macro. Possibly the workaround is similar to what I recently did in hubspot where the star macro is used in the same cte as the get_lead_columns macro. Then the renaming is done in the macro for the permanent fields.
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, @fivetran-joemarkiewicz --I was able to adapt the hubspot strategy into here! My approach:
- added aliases to the get_lead_columns macro
- moved dbt_utils.star to the macro cte. I did have to adjust the approach to work with dbt_utils.star vs. the fivetran_utils from hubspot, but got it working in the end!
- select * as the final select statement
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 see my one unresolved comment for an issue I just came across. Let me know if you want to dig into it more together.
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.
Great work on this @fivetran-catfritz very creative with your solution in the lead staging model!
I only have one required update before merging. Other than that, this is good to go!
-- This will check if there are non-default columns to bring in | ||
{% set default_cols = ['id', 'created_at', 'updated_at', 'email', 'first_name', 'last_name'] %} | ||
{% set new_cols = dbt_utils.star(from=ref('stg_marketo__lead_tmp'), except=default_cols) %} | ||
{% if new_cols != '/* no columns returned from star() macro */' %} |
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 really neat! We definitely will want to keep an eye on this macro in the dependent package to ensure this string doesn't change in the future.
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... I didn't like hard coding the list, but when I tried to fetch the names dynamically like you did in Hubspot, the double quotes were surprisingly hard to deal with. I opted to do the hard code rather than lines and lines of code to replace the double quotes with single quotes needed for dbt_utils.star.
Co-authored-by: Joe Markiewicz <[email protected]>
PR Overview
This PR will address the following Issue/Feature: #32
This PR will result in the following new package version:
Please detail what change(s) this PR introduces and any additional information that should be known during the review of this PR:
custom fields
._fivetran_deleted
filter addedPR 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":
Passthroughs work:
New columns added:
Standard Updates
Please acknowledge that your PR contains the following standard updates:
DECISIONLOG updates have been updated (if applicable)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?
💃