You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We've been toying around with the idea of moving future sqlc exports into an internal sub-package (e.g. db/internal). The idea is to put a more domain-specific facade between the rest of the code and the DB layer. Not that the sqlc code is bad by itself, but it will always remain primarily DB focused - everything there, from the types of optional params, to the types of errors lives and breathes SQL - we'd rather like the rest of the code to think of a bit higher abstraction.
I was wondering if anyone else has done it. Was it worth it in the end? It's quite a bit of boilerplate "facade" code to begin with.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
We've been toying around with the idea of moving future sqlc exports into an internal sub-package (e.g.
db/internal). The idea is to put a more domain-specific facade between the rest of the code and the DB layer. Not that the sqlc code is bad by itself, but it will always remain primarily DB focused - everything there, from the types of optional params, to the types of errors lives and breathes SQL - we'd rather like the rest of the code to think of a bit higher abstraction.I was wondering if anyone else has done it. Was it worth it in the end? It's quite a bit of boilerplate "facade" code to begin with.
BetaWas this translation helpful?Give feedback.
All reactions