-
Notifications
You must be signed in to change notification settings - Fork 20
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] Add employees model, timestamp fixes, add common fields #57
[Feature] Add employees model, timestamp fixes, add common fields #57
Conversation
Add employees model, fix timestamps, and add common 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.
@fivetran-avinash thanks for coordinating with @jmongerlyra to push these changes forward!
I was able to perform and initial review and have a few comments and callouts included in my review below. One major note that jumped out at me is to confirm the usage of the employee
table. I want to make sure we aren't adding a table to be required if we don't see all customers syncing this table. Should we consider adding a variable? I haven't done too much of a deep dive here, but I would like to evaluate if it makes sense to require for all customers or if we should offer more flexibility.
docs/run_results.json
Outdated
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.
Let's remove this file since it's not needed.
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.
Removed,
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 Thanks from some help from @jmongerlyra, this PR is ready for re-review.
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-avinash thanks for working on these updates and @jmongerlyra for chiming in and sharing your insights!
Overall these changes look good! I just have a few final notes to address before this should be good to go! Also, be sure to add the employee disable/enable details in the respective downstream PR #138.
CHANGELOG.md
Outdated
|
||
## Breaking Changes | ||
- Casted specific timestamp fields across all staging models as dates where the Netsuite UI does not perform timezone conversion. Keeping these fields as type timestamp causes issues in reporting tools that perform automatic timezone conversion. | ||
- As this will change the datatype of the underlying fields, this will require a `--full-refresh`. |
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 really won't require a full refresh for the staging models. However, it would be for the downstream ones. Let's clarify that.
- As this will change the datatype of the underlying fields, this will require a `--full-refresh`. | |
- As this will change the datatype of the underlying fields, this will require a `--full-refresh` for downstream incremental models. |
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.
Updated.
CHANGELOG.md
Outdated
|
||
## Feature Updates | ||
- Introduced the `stg_netsuite2__employees` model to bring in data from the `employee` source table. This was brought in to leverage fields like `first_name`, `last_name` and `supervisor` in downstream models in the `dbt_netsuite` transformation package. | ||
- Since this model is only used by a subset of customers, we've introduced the variable `netsuite2__using_employees` to allow users who don't utilize the `employee` table in Netsuite2 the ability to disable that functionality within your `dbt_project.yml`. |
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.
Can you link to the README section to show users how to disable if they are interested.
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.
It actually looks like this wasn't documented in the README. Would you be able to include this in the same section as the other disable/enable variables.
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.
Didn't save the file the first time so it didn't commit. It's in now.
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 This is ready for re-review.
@jmongerlyra I did notice that it was mentioned in the feature that employees fields will be used in downstream models eventually. However, when reviewing the current PR and the other PR you've created, I didn't see any references to employees being brought in yet.
For now, I removed the references from the CHANGELOG, but was curious how would you eventually bring employees fields into the dbt_netsuite
transformation package? Would love to learn more!
@fivetran-avinash We do the joins in a production layer downstream of these models to the transaction dataset. |
Thanks @jmongerlyra ! So there are no plans to bring the |
@fivetran-avinash No immediate plans, but we could since you all have already parameterized the usage. |
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 making these changes @fivetran-avinash and helping address my questions along the way @jmongerlyra! This PR is looking to be in a good position! I have one last required change before this will be good to merge, but it should be a quick one.
Additionally, since the employee model is not used at all downstream at the moment I am a bit cautious/curious if it will impact Quickstart at all (that being the manifest believes it's an end model since it has no downstream dependencies). @fivetran-avinash let's confirm this with our internal team if this will be an issue. If we know it won't then this should be good to go! If it will be an issue, then we can likely avoid it by simply having the default be false
until we decide to use it downstream. Hopefully the addition of the downstream public_models
config ensures this won't be an issue.
models/netsuite2/src_netsuite2.yml
Outdated
description: "{{ doc('employee_table') }}" | ||
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.
Apologies I didn't catch this after the addition of the netsuite2__using_employees
variable, but we need to add a config here to allow the disablement of the employee source if it isn't being used.
description: "{{ doc('employee_table') }}" | |
columns: | |
description: "{{ doc('employee_table') }}" | |
config: | |
enabled: "{{ var('netsuite2__using_employees', true) }}" | |
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.
@fivetran-joemarkiewicz Review comments addressed. Based on Maxwell's response hopefully we are good to go!
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!
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-jamie Release notes addressed!
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!
PR Overview
This PR will address the following Issue/Feature: [#55]
This PR will result in the following new package version: v0.11.0
We changed the data type from timestamp to date for some fields to fix some timezone conversion issues.
Please provide the finalized CHANGELOG entry which details the relevant changes included in this PR:
Breaking Changes
--full-refresh
.Feature Updates
stg_netsuite2__employees
model to bring in data from theemployee
source table. This was brought in to leverage fields likefirst_name
,last_name
andsupervisor
in downstream models in thedbt_netsuite
transformation package.accounts
,subsidiaries
,transaction_lines
,transactions
,transaction_accounting_lines
,customers
, andvendors
within the Netsuite2 staging models.Under the Hood
integration_tests
to support the newstg_netsuite2__employees
model, as well as the new fields introduced into the new Netsuite2 staging models.Contributors
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 share any and all of your validation steps:
The new staging employees model is successfully being passed through and new data types are being applied for timestamp->date conversions. (validated this with integration_tests data).
If you had to summarize this PR in an emoji, which would it be?
🩺