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

Adapters as plugins #966

Closed
beckjake opened this Issue Aug 29, 2018 · 0 comments

Comments

Projects
None yet
3 participants
@beckjake
Copy link
Contributor

beckjake commented Aug 29, 2018

Feature

Adapters should be plugins, installed separately from dbt, and it should be possible for "userspace" to define new adapters.

Feature description

Currently, dbt users who want to support a new adapter type would have to fork dbt, refactor around a number of embedded assumptions about adapters, connection contracts, etc, and maintain that fork. Instead, we should provide a common adapter base class, and define a coherent way for plugins to register themselves as dbt adapters. Plugged-in adapters should be first class, and in fact as part of this we should move all existing adapters into separate packages that dbt can optionally depend upon.

For namespacing, Flask has a nice model here that would leverage with some tweaking and some additions around automatically importing relevant plugins if available.

This is a very big task, and will immediately break all integration tests horribly...

Depends on #960, #961, #962, #963, #965, #953 - maybe more?

Who will this benefit?

Everyone who uses or develops dbt.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment