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

Sqlmesh integration #21655

Open
dbrtly opened this issue May 6, 2024 · 3 comments
Open

Sqlmesh integration #21655

dbrtly opened this issue May 6, 2024 · 3 comments
Labels
area: integrations Related to general integrations, including requests for a new integration type: feature-request

Comments

@dbrtly
Copy link
Contributor

dbrtly commented May 6, 2024

What's the use case?

Similar to the existing dbt integration.
The integration should register models in a sqlmesh project and assets in a dagster project foend to end visibility.

Ideas of implementation

Similar to dbt.

One generic asset definition that enables a library and interprets the sqlmesh models as dagster assets.

Additional information

No response

Message from the maintainers

Impacted by this issue? Give it a 👍! We factor engagement into prioritization

@garethbrickman garethbrickman added the area: integrations Related to general integrations, including requests for a new integration label May 6, 2024
@AlaaInflyter
Copy link

Hey there !
Any news on this ?

@dbrtly
Copy link
Contributor Author

dbrtly commented May 29, 2024

Regarding the design, I would anticipate that the key diff vs dbt is state management. Dbt uses manifest.json, while sqlmesh writes to a sqlmesh schema in your data warehouse or the scheduler's db.

https://sqlmesh.readthedocs.io/en/stable/guides/connections/#overview

My intuition is that we would extend the db_resource to get equivalent asset definitions initially. Agreed?

@AlaaInflyter
Copy link

AlaaInflyter commented May 29, 2024

There's also how environments are handled.
For example: currently, Dagster's docs recommends using cloned DBs, and then you'd make DBT use the correct db depending on the environment.
Since Sqlmesh has a different approach to envs with its plans, there might be need to adjust this recommendation when using sqlmesh?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: integrations Related to general integrations, including requests for a new integration type: feature-request
Projects
None yet
Development

No branches or pull requests

3 participants