On Thursday, 9 January 2025 at 19:49:23 UTC Roland Müller wrote: Reason for that is that doing all DB access methods in the application language (Go or Java) tends to a codebase where you have SQL code snippets scattered over in your code. When the application now grows it will be more and more demanding to make changes. Thus, this does not scale up.
The solution to that problem with sqlc is to *centralize* all your SQL code snippets in one place. This then becomes a set of known, supported interfaces that the application is permitted to use (as an auto-generated, clean Go API). The application cannot use ad-hoc SQL. If the application author finds they need to use a different SQL query, then they get it added to the corpus of SQL snippets. There it can be tested, reviewed, sanity-checked for performance implications etc. You can also easily find which piece of code uses which snippet. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/c92d599d-3d83-466d-8b9f-e53969ca3b20n%40googlegroups.com.
