-
Notifications
You must be signed in to change notification settings - Fork 2
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/order to orders #12
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 this looks great! I just have a few small suggestions. Mainly I want to get your thoughts around if we should still test in our integration_test when the connector uses the order
naming convention.
Other than that, this looks great! Let me know once you take a look and I can re-review.
Co-authored-by: Joe Markiewicz <[email protected]>
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 for the review! I have updated based on your comments. I tried a few different ways for getting the source 'order' to cooperate with the integrations test, but I had to go back to the way I had originally set it up. The issue is that the source has quoting set to true instead of there being issues with the column names like we discussed earlier.
Let me know if this looks good to go 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.
LGTM after docs are regenerated!
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.
just one comment on the src.yml! otherwise approved
@@ -425,6 +425,51 @@ sources: | |||
- name: _fivetran_synced | |||
description: "{{ doc('_fivetran_synced') }}" | |||
|
|||
- name: orders # applies to connectors created on or after 2024-06-18 |
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.
should we disable this source based on recharge__using_orders
?
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.
potentially also using the recharge_does_table_exist
macro if possible
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 I hand't considered that, so I'm flexible either way! Could you explain the benefits?
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 question! Not much since we don't have any freshness tests in this package haha
Only benefit I can think of is getting rid of a floating orders
source entity in the DAG for people who don't have it yet. Not super high priority, especially given that there's not an easy way to get rid of a floating order
source in the DAG for people with orders
.
Honestly let's leave it as is. I feel like it's more beneficial to potentially call people's attention to the upcoming ORDERS
transition
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:
Test 1
Seeded both tables
ORDERS
andORDER
Ran updates with no variable set and checked that it correctly compiled to select
ORDERS
in this case.Test 2
Seeded both tables
ORDERS
andORDER
Set var
recharge__using_orders: false
and checked that it correctly compiled to selectORDER
in this case.Test 3
Seeded only table
ORDER
Ran updates with no variable set and checked that it correctly compiled to select
ORDER
in this case.If you had to summarize this PR in an emoji, which would it be?
🍔