You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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") }} asdate) 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.
The text was updated successfully, but these errors were encountered:
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.
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.
Is there an existing feature request for this?
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?
Anything else?
One error from the dry runner is this case statement:
dbt_zendesk/models/ticket_history/int_zendesk__field_calendar_spine.sql
Line 24 in 3af26a7
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 dunmodel.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.The text was updated successfully, but these errors were encountered: