Sqlc: Data access simplified. Throw away your ORM

Re:Sqlc: Data access simplified. Throw away your ORM by bvrmn on Wednesday December 04, 2024 @07:33AM (#42316810)

How 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).

[ Parent | on HN ]

Re:Sqlc: Data access simplified. Throw away your ORM by jbverschoor on Wednesday December 04, 2024 @07:40AM (#42316865)

Use hql named queries with named parameters

[ Parent | on HN ]

Re:Sqlc: Data access simplified. Throw away your ORM by bvrmn on Wednesday December 04, 2024 @08:26AM (#42317213)

What's hql? If it's something related to hybernate than your comment is slightly out of context.

[ Parent | on HN ]

Re:Sqlc: Data access simplified. Throw away your ORM by jbverschoor on Wednesday December 04, 2024 @09:29AM (#42317727)

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

[ Parent | on HN ]

Re:Sqlc: Data access simplified. Throw away your ORM by bvrmn on Wednesday December 04, 2024 @11:05AM (#42318820)

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

[ Parent | on HN ]

Re:Sqlc: Data access simplified. Throw away your ORM by mrastro on Wednesday December 04, 2024 @11:37AM (#42319165)

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.

[ Parent | on HN ]

Re:Sqlc: Data access simplified. Throw away your ORM by dhfuuvyvtt on Tuesday December 10, 2024 @04:55AM (#42375361)

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)

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.

[ Parent | on HN ]