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

[CT-408] [Feature] Database Agnostic error handling #4926

Closed
1 task done
McKnight-42 opened this issue Mar 22, 2022 · 1 comment
Closed
1 task done

[CT-408] [Feature] Database Agnostic error handling #4926

McKnight-42 opened this issue Mar 22, 2022 · 1 comment
Labels
enhancement New feature or request tech_debt Behind-the-scenes changes, with little direct impact on end-user functionality

Comments

@McKnight-42
Copy link
Contributor

Is there an existing feature request for this?

  • I have searched the existing issues

Describe the Feature

Per #4858 (comment) the way we are catching database errors needs to be handled in a way that leverages each databases level of concern for the error or to catch them, and turn them into dbt specific errors and run those against tests

Describe alternatives you've considered

currently catching and lowering error to be read out same way across databases.

Who will this benefit?

potential for all uses to benefit as errors could be written very clearly across all databases.

Are you interested in contributing this feature?

No response

Anything else?

No response

@McKnight-42 McKnight-42 added enhancement New feature or request triage and removed triage labels Mar 22, 2022
@github-actions github-actions bot changed the title [Feature] Database Agnostic error handling [CT-408] [Feature] Database Agnostic error handling Mar 22, 2022
@McKnight-42 McKnight-42 added the tech_debt Behind-the-scenes changes, with little direct impact on end-user functionality label Mar 22, 2022
@jtcohen6
Copy link
Contributor

@McKnight-42 The error message we're catching here is specific to the test added in #4858, and it's actually handled in a database-agnostic way there. We'll find out when we convert the test cases to use the new pytest-based framework, and set them up to be inherited and run (with zero code changes) in each of our plugins. Then, we can delete the copy-pasted code that lives in the plugins currently.

I think this can be closed, since the main work is already reflected in #4882

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request tech_debt Behind-the-scenes changes, with little direct impact on end-user functionality
Projects
None yet
Development

No branches or pull requests

2 participants