-
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
Nov 2024 schema #32
base: main
Are you sure you want to change the base?
Nov 2024 schema #32
Conversation
…sistency test, update changelog
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-reneeli thanks for this PR. A few comments below following this review.
|
||
{% set first_date_query %} | ||
|
||
select min(date_day) as min_date_day |
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.
If this makes sense, I will add the subscription staging models too. Just wanted to have a proof of concept first before spending time adding the subscription logic.
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.
So the idea here is to get a date spine generated using the earliest date across all events and then use that earliest date as the starting point? I think this is a good approach!
However, to brainstorm a bit more - is there a simper way we could achieve this by using one table? This could be a performance update in the future, but I want to think through this. Can we make the claim that crashes and engagements wouldn't come until there is a download and therefore could just rely on the min date of the download daily? I'm not saying that's true, but want to think through any of these simpler possibilities.
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.
Not required for pre-release, but wanting to bump this question to ensure it doesn't get lost.
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-reneeli please see my review comments below. There are a few change requests that will require a number of changes. Let me know if you would like to sync on any of my comments or open ended questions and approaches.
Ultimately, once the date spine issue is sorted out the end reports will be in a good spot! Although we will want to get the other comments addressed before pre-release.
|
||
{% set first_date_query %} | ||
|
||
select min(date_day) as min_date_day |
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.
So the idea here is to get a date spine generated using the earliest date across all events and then use that earliest date as the starting point? I think this is a good approach!
However, to brainstorm a bit more - is there a simper way we could achieve this by using one table? This could be a performance update in the future, but I want to think through this. Can we make the claim that crashes and engagements wouldn't come until there is a download and therefore could just rely on the min date of the download daily? I'm not saying that's true, but want to think through any of these simpler possibilities.
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.
A few change requests and questions. Once these are addressed this should be ready for release review for pre-release.
|
||
{% set first_date_query %} | ||
|
||
select min(date_day) as min_date_day |
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.
Not required for pre-release, but wanting to bump this question to ensure it doesn't get lost.
packages.yml
Outdated
- git: https://github.com/fivetran/dbt_apple_store_source.git | ||
revision: nov_2024_schema | ||
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.
Reminder that this will need to be the following before cutting the pre-release.
- git: https://github.com/fivetran/dbt_apple_store_source.git | |
revision: nov_2024_schema | |
warn-unpinned: false | |
- package: fivetran/apple_store_source | |
version: 0.5.0-a1 |
Co-authored-by: Joe Markiewicz <[email protected]>
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.
A few small change requests before approval
@@ -1,4 +1,14 @@ | |||
# dbt_apple_store version.version | |||
# dbt_apple_store v0.5.0-a1 |
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.
Same comment from the source to create a duplicate entry for the official v0.5.0 release while also retaining the v0.5.0-a1 release for posterity.
@@ -54,7 +55,7 @@ Include the following apple_store package version in your `packages.yml` file: | |||
```yaml | |||
packages: | |||
- package: fivetran/apple_store | |||
version: [">=0.4.0", "<0.5.0"] # we recommend using ranges to capture non-breaking changes automatically | |||
version: 0.5.0-a1 |
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 needs to now reflect what will be the updated official range.
@@ -146,7 +147,7 @@ This dbt package is dependent on the following dbt packages. These dependencies | |||
```yml | |||
packages: | |||
- package: fivetran/apple_store_source | |||
version: [">=0.4.0", "<0.5.0"] | |||
version: v0.5.0-a1 |
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 will need to now be the updated official range of the source
# dbt_apple_store v0.5.0-a1 | ||
[PR #32](https://github.com/fivetran/dbt_apple_store/pull/32) includes the following updates: | ||
|
||
## Breaking Changes: Schema Change |
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.
I would also add in here the bugfix of materializing the reporting grains as tables. This will result in extra tables, but it's important to highlight why this change was made.
- git: https://github.com/fivetran/dbt_apple_store_source.git | ||
revision: nov_2024_schema | ||
warn-unpinned: false | ||
|
||
# - package: fivetran/apple_store_source | ||
# version: 0.5.0-a1 |
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.
Reminder that this will need to be updated before merge and release
PR Overview
This PR will address the following Issue/Feature: #28
This PR will result in the following new package version: v0.5.0-a1
Schema changes from Nov 2024
Please provide the finalized CHANGELOG entry which details the relevant changes included in this PR:
to be completed
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:
If you had to summarize this PR in an emoji, which would it be?
💃