11–20 of 109 posts
This kind of generates the type safe queries for you, which is the end goal. But then why don't developers use the query builder instead? Why have an unnecessary generation step?
I feel like a good query builder ORM is more than enough and more straightforward than this. What am I missing?
I've always said that the best ORM is one that allows for type safe query building. This kind of generates the type safe queries for you, which is the end goal. But then why don't developers use the query builder instead? Why have an unnecessary generation step? I feel like a good query builder ORM is more than enough and more straightforward than this. What am I missing?
I've always said that the best ORM is one that allows for type safe query building. This kind of generates the type safe queries for you, which is the end goal. But then why don't developers use the query builder instead? Why have an unnecessary generation step? I feel like a good query builder ORM is more than enough and more straightforward than this. What am I missing?
Many times I’ve been stuck in a place where I knew exactly how to write the SQL for it but had to spend several minutes studying the ORM docs to learn how to express it.
SQLc also has the advantage of static checking your queries.
It has some other disadvantages so it’s not all rosy.
I don't work with Go, but this seems like a dream. I really like the SQLx query macros in Rust. I would love for something like this
https://docs.sqlc.dev/en/latest/reference/language-support.h...
Surprisingly not Java, but probably pretty easy to add support for more.
I remember using https://sqlfairy.sourceforge.net/ back in the day to help test locally against mysql/postgres, but deploy to oracle. There were hiccups, but it felt like the world would mostly converge onto smaller differences between the offerings and that kicking off a test database on every build should be easier as time goes on.
Instead, it feels like we have done as much as we can to make all of this harder. I loved AWS Athena when I was able to use it, but trying to figure out a local database for testing that supported the same dialect it used seemed basically impossible. It was baffling.
I've always said that the best ORM is one that allows for type safe query building. This kind of generates the type safe queries for you, which is the end goal. But then why don't developers use the query builder instead? Why have an unnecessary generation step? I feel like a good query builder ORM is more than enough and more straightforward than this. What am I missing?
The query builder is yet another mini language that you have to learn and they change for each ORM so learning one is mostly wasted time. Many times I’ve been stuck in a place where I knew exactly how to write the SQL for it but had to spend several minutes studying the ORM docs to learn how to express it. SQLc also has the advantage of static checking your queries. It has some other disadvantages so it’s not all ros…
I remain baffled that standard SQL isn't more supported by some of the newer tools coming out. If you are targeting a standard SQL dialect, it is basically trivial to standup an local database to test against during every build. I remember using https://sqlfairy.sourceforge.net/ back in the day to help test locally against mysql/postgres, but deploy to oracle. There were hiccups, but it felt like the world would most…
I've been looking into sqlc lately for Go. Seems brilliant except for the lack of dynamic queries: https://github.com/sqlc-dev/sqlc/discussions/364
sqlc lacking support for dynamic query generation is just absolutely baffling. Composition of query fragments is, like, one of the main reasons you use a query builder - it's very hard to do in raw SQL! If you don't need that feature, why are you even messing around with SQL code on the application side? Just write and call stored procedures in the database! People will think you're a time traveler from the 1980's but it works!
Golang's SQL ecosystem is... pretty miserable, really. I mean, I look at what jOOQ can do and I weep at the state of things over in go. In golang everything goes through database/sql because that's the "standard" solution, but database/sql is a huge mess with a long track record of disastrous bugs (like the possibility of accidentally running queries outside of the intended transaction) that makes it very hard to take advantage of feature-rich databases like postgres. pgx (postgres connection library) is actually quite good when you use its native API, but because everything has to go through the database/sql interface it gets pretty crippled with a lot of annoyances (try mapping postgres arrays or jsonb documents into structs and you'll see what I mean).