Sqlc: Data access simplified. Throw away your ORM • Hacker News Board

Re: Sqlc: Data access simplified. Throw away your ORM

#21

Post by mrastro » Wed, Dec 04, 2024, 4:37 PM UTC

bvrmn wrote: post #13

dhfuuvyvtt wrote: post #7

Earlier quoted context omitted.

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.

How SQLc would solve following issue. For example I have original query: SELECT * from users where following_count > $1 and followers_count Then some refactoring later it becomes: SELECT * from users where enabled and followers_count $2; As I understand go API would not change it still query(int, int).

Is 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.

Re: Sqlc: Data access simplified. Throw away your ORM

#22

Post by dhfuuvyvtt » Tue, Dec 10, 2024, 9:55 AM UTC

bvrmn wrote: post #13

dhfuuvyvtt wrote: post #7

Earlier quoted context omitted.

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.

How SQLc would solve following issue. For example I have original query: SELECT * from users where following_count > $1 and followers_count Then some refactoring later it becomes: SELECT * from users where enabled and followers_count $2; As I understand go API would not change it still query(int, int).

I'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.

Re: Sqlc: Data access simplified. Throw away your ORM

#23

Post by dhfuuvyvtt » Tue, Dec 10, 2024, 9:57 AM UTC

bvrmn wrote: post #3

Numbered 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.

Its 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. :)

Re: Sqlc: Data access simplified. Throw away your ORM

#24

Post by [deleted] » Sat, Dec 14, 2024, 9:45 AM UTC

bvrmn wrote: post #14

dhfuuvyvtt wrote: post #12

Earlier quoted context omitted.

Simple 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 lear…

I 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.

[deleted]