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

[Feature] Support dbt-dry-run #91

Open
2 of 4 tasks
tim-summerton-brier opened this issue Mar 8, 2023 · 2 comments
Open
2 of 4 tasks

[Feature] Support dbt-dry-run #91

tim-summerton-brier opened this issue Mar 8, 2023 · 2 comments
Labels
enhancement New feature or request

Comments

@tim-summerton-brier
Copy link

Is there an existing feature request for this?

  • I have searched the existing issues

Describe the Feature

We use dbt-dry-run when deploying our dbt code to check for any errors. On a dbt project using this package, dbt-dry-run will fail if you try to run it before the models have been run. Once the models have been run once and generated some data in BigQuery, the dry run will succeed.

Please can you support dbt-dry-run without having to run the models prior to the dry run?

Describe alternatives you've considered

No response

Are you interested in contributing this feature?

  • Yes.
  • Yes, but I will need assistance and will schedule time during your office hours for guidance.
  • No.

Anything else?

One error from the dry runner is this case statement:

cast( {{ dbt.date_trunc('day', "case when status != 'closed' then " ~ dbt.current_timestamp_backcompat() ~ " else updated_at end") }} as date) as open_until

It complains the two return values are of different types.
No matching signature for operator CASE; all THEN/ELSE arguments must be coercible to a common type but found: STRING, TIMESTAMP; actual argument types (WHEN THEN) ELSE: (BOOL TIMESTAMP) STRING at [162:14]

I believe the fix for this issue is to wrap updated_at with a cast to timestamp, but I've not tested this.

Another set of errors it raises is it can't find any of the fields from ticket_field_history_columns in the schema of upstream models when trying to dry dun model.zendesk.zendesk__ticket_backlog. I imagine the root cause of this is that these fields are not physical columns in the source data. This will require further investigation from someone more familiar with this package.

@tim-summerton-brier tim-summerton-brier added the enhancement New feature or request label Mar 8, 2023
@fivetran-joemarkiewicz
Copy link
Contributor

Hi @tim-summerton-brier thanks for opening this feature request!

We typically only provide support for our package within the framework of native dbt Core functionality. I have never used dbt-dry-run myself, but curious to see what components are not compatible with this package. I actually wonder, are you able to run dbt-dry-run with other modeling type packages? The error it is showing you currently with the case statement seems like it is an issue with reading the dbt macro and not understanding it is a timestamp 🤔.

I wonder if there may be some cases where dbt-dry-run was not intended to work natively with dbt packages.

@tim-summerton-brier
Copy link
Author

We currently have dbt-dry-runner working on a dbt project using the fivetran_log package, but we introduced the dry runner later on in that project, so data had already been generated. I'm not sure if the dry runner would have worked prior to generating data with fivetran_log.

The workaround we've employed for our current project is to disable the dry runner, deploy and run our dbt project to generate the data, then re-enable the dry runner.

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

No branches or pull requests

2 participants