-
Notifications
You must be signed in to change notification settings - Fork 752
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
Labels
enhancement
New feature or request
Comments
I'd like that too! |
I hope this is done soon |
5 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 theapplication
layer, whereas the implementations of the repositories should live in theinfrastructure
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 inapplication/repository
, and the SQL query strings and implementations ininfrastructure/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 myapplication
layer now points to theinfrastructure
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
The text was updated successfully, but these errors were encountered: