fix/datespine-empty

[fivetran-joemarkiewicz]

PR Overview

This PR will address the following Issue/Feature: Issue #118

This PR will result in the following new package version: v0.12.3

This is simply adding default start and end dates to the int_quickbooks__general_ledger_date_spine model. This will not result in breaking changes. Instead it will ensure users who do not yet have transactions are able to see success in the end models.

Please provide the finalized CHANGELOG entry which details the relevant changes included in this PR:

Bug Fixes

• Included a default start and end date in the int_quickbooks__general_ledger_date_spine logic when generating the date spine. These default start and end dates will ensure the model still succeeds when no transactions are yet available.
  • The default start date will be one month in the past
  • The default end date will be the current date

Under the Hood

• Updated the maintainer PR template to resemble the most up to date format.
• Removed the check docs GitHub Action as it is no longer necessary.

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:

To validate these changes, I first attempted to run the QuickBooks data model on a schema where no transactions were present (I did this by just choosing a non existent schema to run the package against) and installed the production version of the data model. After doing this, I was able to see the run failed with the same error highlighted in the issue.

I then wanted to confirm that when using the same non existent schema (to emulate a schema with no transactions) that the data model would succeed given the changes in this PR. I was able to validate that these changes do in fact result in the expected outcome.

Further, I can confirm that this causes no issues on schemas that do have transactions present in the source schema. See in the screenshot below how prod and dev both have the same min and max dates in the general ledger date spine before/after this update is applied. Therefore, existing users will not experience any changes and this will simply address the issue when customers do not have transactions present.

If you had to summarize this PR in an emoji, which would it be?

📆

[fivetran-jamie]

lgtm! should we make a quickbooks version of this exploratory issue as well? fivetran/dbt_salesforce#49

[fivetran-joemarkiewicz]

lgtm! should we make a quickbooks version of this exploratory issue as well? fivetran/dbt_salesforce#49

That is great callout. Maybe we just consolidate QuickBooks in the FR you referenced for Salesforce. I believe when we get around to that FR we can explore the suggestion with all other datespine models in mind. As it will probably be relevant for all others as well.

[fivetran-joemarkiewicz]

Following the recent casting changes, I can confirm the results are still what we would expect.

• No changes between dev (the changes from this PR) and prod (live version of the package) when looking at the min and max dates.
• Prod with no transactions doesn't exist because it failed as the original issue details
• Dev with no transactions succeeds due to the changes in this PR but have no data as expected.