Skip to content
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

Open
wants to merge 51 commits into
base: main
Choose a base branch
from
Open

Nov 2024 schema #32

wants to merge 51 commits into from

Conversation

fivetran-reneeli
Copy link
Contributor

@fivetran-reneeli fivetran-reneeli commented Jan 31, 2025

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:

  • dbt run –full-refresh && dbt test
  • dbt run (if incremental models are present) && dbt test

Before marking this PR as "ready for review" the following have been applied:

  • The appropriate issue has been linked, tagged, and properly assigned
  • All necessary documentation and version upgrades have been applied
  • docs were regenerated (unless this PR does not include any code or yml updates)
  • BuildKite integration tests are passing
  • Detailed validation steps have been provided below

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?

💃

Copy link
Collaborator

@fivetran-joemarkiewicz fivetran-joemarkiewicz left a 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.

models/apple_store__app_version_report.sql Outdated Show resolved Hide resolved
models/apple_store__app_version_report.sql Outdated Show resolved Hide resolved
models/apple_store__app_version_report.sql Outdated Show resolved Hide resolved

{% set first_date_query %}

select min(date_day) as min_date_day
Copy link
Contributor Author

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.

Copy link
Collaborator

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.

Copy link
Collaborator

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.

Copy link
Collaborator

@fivetran-joemarkiewicz fivetran-joemarkiewicz left a 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.

README.md Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
packages.yml Outdated Show resolved Hide resolved
models/intermediate/int_apple_store__date_spine.sql Outdated Show resolved Hide resolved
CHANGELOG.md Outdated Show resolved Hide resolved
DECISIONLOG.md Outdated Show resolved Hide resolved
models/apple_store__app_version_report.sql Outdated Show resolved Hide resolved
models/intermediate/int_apple_store__date_spine.sql Outdated Show resolved Hide resolved

{% set first_date_query %}

select min(date_day) as min_date_day
Copy link
Collaborator

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.

models/apple_store__app_version_report.sql Outdated Show resolved Hide resolved
Copy link
Collaborator

@fivetran-joemarkiewicz fivetran-joemarkiewicz left a 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.

CHANGELOG.md Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
dbt_project.yml Outdated Show resolved Hide resolved

{% set first_date_query %}

select min(date_day) as min_date_day
Copy link
Collaborator

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
Comment on lines 2 to 4
- git: https://github.com/fivetran/dbt_apple_store_source.git
revision: nov_2024_schema
warn-unpinned: false
Copy link
Collaborator

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.

Suggested change
- 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

models/apple_store__territory_report.sql Outdated Show resolved Hide resolved
models/apple_store__territory_report.sql Outdated Show resolved Hide resolved
models/apple_store__territory_report.sql Outdated Show resolved Hide resolved
models/apple_store.yml Show resolved Hide resolved
README.md Show resolved Hide resolved
Copy link
Collaborator

@fivetran-joemarkiewicz fivetran-joemarkiewicz left a 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
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Collaborator

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.

Comment on lines +2 to +7
- 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
Copy link
Collaborator

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants