Bug/event casting

[fivetran-catfritz]

PR Overview

This PR will address the following Issue/Feature: Internal ticket

This PR will result in the following new package version:

• v0.5.1

Please detail what change(s) this PR introduces and any additional information that should be known during the review of this PR:

• The original issue was from an internal ticket. Customer was getting this error:

Database Error in model int_klaviyo__event_attribution (models/intermediate/int_klaviyo__event_attribution.sql)
00:39:53    function pg_catalog.date_add("unknown", integer, timestamp with time zone) does not exist
00:39:53    HINT:  No function matches the given name and argument types. You may need to add explicit type casts.

• I was able to recreate this issue by forcing our seed data type to timezone with timestamp:

+column_types:
      _FIVETRAN_SYNCED: timestamptz

• It give me the same error on the incremental/subsequent run.
  

• This specific issue was fixed by casting _fivetran_synced in the source event model via cast(_fivetran_synced as {{ dbt.type_timestamp() }}) as _fivetran_synced which flows into the int_klaviyo__event_attribution model.

• After internal discussion with the data and solutions team, we decided it would be best to cast all IDs used in downstream joins or coalesce functions as string to avoid any downstream discrepancies.

• The changes included in this PR include the timezone cast and the string casts.

PR Checklist

Basic Validation

Please acknowledge that you have successfully performed the following commands locally:

• dbt compile
• dbt run –full-refresh
• dbt run
• dbt test
• dbt run –vars (if applicable)

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

• The appropriate issue has been linked and tagged (internal ticket only)
• You are assigned to the corresponding issue and this PR
• BuildKite integration tests are passing

Detailed Validation

Please acknowledge that the following validation checks have been performed prior to marking this PR as "ready for review":

• You have validated these changes and assure this PR will address the respective Issue/Feature.
• You are reasonably confident these changes will not impact any other components of this package or any dependent packages.
• You have provided details below around the validation steps performed to gain confidence in these changes.

• The timestamp datatype issue is resolved as described above. The remaining changes are precautionary.

• I also tested the changes in downsteam package via this branch, and everything ran smoothly.

Standard Updates

Please acknowledge that your PR contains the following standard updates:

• Package versioning has been appropriately indexed in the following locations:
  • indexed within dbt_project.yml
  • indexed within integration_tests/dbt_project.yml
• CHANGELOG has individual entries for each respective change in this PR
• README updates have been applied (if applicable)
• DECISIONLOG updates have been updated (if applicable)
• Appropriate yml documentation has been added (if applicable)

dbt Docs

Please acknowledge that after the above were all completed the below were applied to your branch:

• docs were regenerated (unless this PR does not include any code or yml updates)

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

⌨️

[fivetran-joemarkiewicz]

@fivetran-catfritz these changes look good to me! However, I do just want to confirm one small question - Can you confirm that setting these datatypes in the source won't have any impact on the incremental models in the transform? For example, what happens if the datatype of one of these fields is not a string or timestampntz at the moment, but then after this change they do in fact change upstream. What would happen to the incremental models downstream?

Are the incremental models able to pick up the change without a fuss or is this something that would result in a failure in the model? This may be a fringe case, but I want to make sure this patch update couldn't break anything in an unforeseen way.

[fivetran-catfritz]

@fivetran-joemarkiewicz I see what you mean. The incremental run will have an error if the datatype changes after the initial run. Since we can't guarantee a user's current datatypes, would it be safer to make this a breaking change? I was hoping to avoid updating the transform and hollistic reporting with a breaking change, but then again that probably amplifies the risk too.

[fivetran-catfritz]

@fivetran-joemarkiewicz I have updated this PR to be breaking and added this transform PR. The hollistic package update will be for another day due to Shopify also needing updates.

[fivetran-joemarkiewicz]

LGTM