4 ms·
Sqlc: Data access simplified. Throw away your ORM
- jasfi 2y agoThis is cool, but most ORMs have support for raw SQL.
- Alifatisk 2y agoWe have achieved at a point were we call SQL "raw". Am I this old?
- poincaredisk 2y agoI've been hearing people calling SQL "raw" for the past 10 years so... probably?
- jasfi 2y agoIt's only called "raw" when called from an ORM, as opposed to generated SQL.
- bvrmn 2y agoIt became raw since query builders started to try to mimic SQL. Quite long ago.
- dhfuuvyvtt 2y agoSQLc 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.
- bvrmn 2y agoHow SQLc would solve following issue. For example I have original query: SELECT * from users where following_count > $1 and followers_count < $2; Then some refactoring later it becomes: SELECT * from users where enabled and followers_count < $1 and following_count > $2; As I understand go API would not change it still query(int, int).
- jbverschoor 2y agoUse hql named queries with named parameters
- bvrmn 2y agoWhat's hql? If it's something related to hybernate than your comment is slightly out of context.
- jbverschoor 2y agoHibernate Query Language. How is it out of context? 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.
- bvrmn 2y agoI did not object against ORMs. Please reread thread. I also have issues with SQLc, and please note it's Go library. Java is out of context.
- dhfuuvyvtt 2y agoI'm not sure that's an issue? It would be an odd refactor to add a new side effect to the query you didn't want to apply across the board. 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.
- mrastro 2y agoIs the question about how to version the query? You have comments before the query that allow you to name the exported function so you could have both queries and name them something different.
- bvrmn 2y agoNumbered parameters become fragile quite fast for even simple queries. Basically you couldn't safely use query until carefully revising a template. A template change could potentially break existing queries. It's kinda scary. If library supports named parameters they should be used by default in examples.
- dhfuuvyvtt 2y agoIts probably to be consistent across each platform, MySQL doesn't support named queries so they are likely avoiding using them for that reason, either that or the docs are old. :)
- bvrmn 2y agoStatic templates for SQL becomes a chore to express dynamic queries. A dynamic query depends from incoming request. For example search filters should add or delete conditional expressions for a query. I have a little research[1] on dynamic queries. [1]: https://github.com/baverman/sqlbind?tab=readme-ov-file#dynamic-queries https://github.com/baverman/sqlbind?tab=readme-ov-file#dynam...
- dhfuuvyvtt 2y agoIf you're writing a lot of dynamic queries I think you should opt for a query builder, not an orm. For me, I write almost nothing but static queries, SQLc is just so much nicer to use. I don't mind having to do the odd dynamic query from scratch. I just wish sqlc supported named Params in MySQL, the resulting function param ordering is a little annoying.
- bvrmn 2y agoThe issue with templates they could handle only simple cases or very specific complex static queries. Simple ones are a way easier with ORM/query builder. Highly depends from ORM though. And a big NO-NO for me templates force you to repeat the same SQL in many slightly different queries. SQL composability is not a thing with templates.
- dhfuuvyvtt 2y agoSimple queries aren't any easier with ORM, that's the point of sqlc, you write the SQL and then call it as a function. There's no extra abstraction or added steps on top. Repeating portions of sql isnt really an issue for me either, it's the business end of the database, you want it all there in one location, spreading it around in a composible fashion is just one abstraction too far. I know SQL, I don't want to learn anything else on top.
- bvrmn 2y agoI guess you talk from only a Go perspective where you don't know any good ORM libraries. Other languages have quite convenient ORMs. Some allows even auto migrations, creating migration SQL for your.
- topicseed 2y agoA great option for Go projects where you aren't exploring your queries as changing and regenerating is cumbersome. Also, SQLC doesn't allow for dynamic query building so think about an input search struct from which you may add where clauses — or not. Also doesn't support multiple inserts with N rows being inserted. Otherwise for standard queries, it's great.