This is cool, but most ORMs have support for raw SQL.
We have achieved at a point were we call SQL "raw". Am I this old?
It became raw since query builders started to try to mimic SQL. Quite long ago.
Sqlc: Data access simplified. Throw away your ORM
11–20 of 24 posts
Re: Sqlc: Data access simplified. Throw away your ORM
#12Earlier quoted context omitted.
If 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.
The 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.
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 learn anything else on top.
Re: Sqlc: Data access simplified. Throw away your ORM
#13This is cool, but most ORMs have support for raw SQL.
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 SELECT * from users where enabled and followers_count $2;
Re: Sqlc: Data access simplified. Throw away your ORM
#14Earlier quoted context omitted.
The 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.
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.
Re: Sqlc: Data access simplified. Throw away your ORM
#15Earlier 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).
Use hql named queries with named parameters
Re: Sqlc: Data access simplified. Throw away your ORM
#16Earlier quoted context omitted.
The 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.
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 did a quick look at GORM. And it's a way easier and safer to use for simple cases.
Re: Sqlc: Data access simplified. Throw away your ORM
#17Earlier quoted context omitted.
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).
Use hql named queries with named parameters
What's hql? If it's something related to hybernate than your comment is slightly out of context.
Re: Sqlc: Data access simplified. Throw away your ORM
#18Earlier quoted context omitted.
Use hql named queries with named parameters
What's hql? If it's something related to hybernate than your comment is slightly out of context.
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.
Re: Sqlc: Data access simplified. Throw away your ORM
#19A 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.
Re: Sqlc: Data access simplified. Throw away your ORM
#20Earlier quoted context omitted.
What's hql? If it's something related to hybernate than your comment is slightly out of context.
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.
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.