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

Config option to split generation paths #1951

Open
taylow opened this issue Nov 10, 2022 · 4 comments
Open

Config option to split generation paths #1951

taylow opened this issue Nov 10, 2022 · 4 comments
Labels
enhancement New feature or request

Comments

@taylow
Copy link

taylow commented Nov 10, 2022

What do you want to change?

I use SQLC to generate data storage model, repository interfaces, and their implementations from SQL files (obviously!), and absolutely love what the tool offers. I'm constantly recommending it.

I have recently started the transition towards Clean Architecture in the project I'm work on, using a layered approach to separate concerns (e.g. domain, application, infrastructure, presentation, etc.), and unfortunately have hit a small problem with the generated SQLC files.

The interface definition of repositories (Querier in SQLC) and DSOs should live in the application layer, whereas the implementations of the repositories should live in the infrastructure layer.

At the moment, SQLC generates all files into one folder determined by the path parameter of the config.

My proposal is to allow overrides for each of the generated files. This would fix my problem, as I could generate the Querier and models in application/repository, and the SQL query strings and implementations in infrastructure/repository.

I could wrap SQLC in a custom repository interface, but I really like the fact that the repository interface and models are generated from our SQL. My temporary solution is defining a new interface that embeds the Querier, but the direction of inversion is broken, as my application layer now points to the infrastructure layer, which is incorrect in Clean Architecture. I could also just suck it up and keep SQLC files in the application layer, but then we have infrastructure concerns in the application, which is also incorrect.

Any thoughts on this? If this is something that other want/see a use for, I can take a look at opening a PR (eventually). Any input is appreciated 🙏

What database engines need to be changed?

No response

What programming language backends need to be changed?

No response

@taylow taylow added enhancement New feature or request triage New issues that hasn't been reviewed labels Nov 10, 2022
@taylow
Copy link
Author

taylow commented Nov 10, 2022

Looks like there are two issues that want a similar feature for models (#835 and #1941), whereas this is about breaking out all generation paths

@andrewmbenton andrewmbenton removed the triage New issues that hasn't been reviewed label Jun 6, 2023
@mpyw
Copy link
Contributor

mpyw commented Jul 6, 2023

#1941 (comment)

@vezzalinistefano
Copy link

I'd like that too!

@anhnmt
Copy link

anhnmt commented Jan 2, 2024

I hope this is done soon

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

5 participants