SQLc isn't just raw SQL.
SQLc you write the queries, it generates the boilerplate functions to execute them.
This works better than an ORM because you don't have to deal with an ORM.
SQLc you write the queries, it generates the boilerplate functions to execute them.
This works better than an ORM because you don't have to deal with an ORM.
For example I have original query:
SELECT * from users where following_count > $1 and followers_count < $2;
SELECT * from users where enabled and followers_count < $1 and following_count > $2;
Use Named Native Query and you have SQL queries.
I really don’t understand the objection to ORMs. By that logic, you might as well reserve a block of memory and offsets instead of class/struct attributes.
More likely you would introduce a new query that would get a new function call.
usersWithCountBetween(a, b)
vs
enabledUsersWithCountBetween(a,b)
If you mean, how to handle the addition of a new enabled flag that is passed in, that too would either require refactoring or a new function.
These aren't really things I would consider a problem but maybe I'm missing something?
Oh and you can configure the number of params before it replaces the params with an interface so things like this are easier to manage over time.