3 ms·
The hate should be directed at SQL builder part of most ORMs. Which gets complicated pretty quickly, and it's like learning a new language when SQL works usuall
by Ciantic 5y ago
The hate should be directed at SQL builder part of most ORMs. Which gets complicated pretty quickly, and it's like learning a new language when SQL works usually much better.
If you write your SQL, and some tool, like code generation, then maps it to object, you are golden. It's the part you'd have to write anyway. However if the code generation goes bust (like gets abandoned like most hobby mappers), you should make sure you can take the code and continue like you never used the generator in the first place.
It looks like the authors suggestion SQLC is pretty close to that. It seems to generate a lot of code though, so it might be an issue if you don't want to maintain SQLC, test it out in here: https://play.sqlc.dev/ https://play.sqlc.dev/
- hn_throwaway_99 5y agoI've been a huge fan of Slonik, https://github.com/gajus/slonik https://github.com/gajus/slonik, which makes it easy and safe to write direct SQL queries. The author of Slonik had a good article about the downsides of query builders, previously discussed on HN, that I totally agree with: https://gajus.medium.com/stop-using-knex-js-and-earn-30-bf410349856c https://gajus.medium.com/stop-using-knex-js-and-earn-30-bf41...
- meitham 5y agoOn the contrary, I hate dealing with the various escaping characters for SQL, and to me SQLAlchemy expression is a life-saver. It gives me back a textual sql expression as a string and I can choose exactly how to run it. I do avoid the ORM part as I like to be in total control of the transaction, and I am often in the python async world, where ORM don't play nicely.
- hn_throwaway_99 5y ago> I hate dealing with the various escaping characters for SQL I don't understand that bit, with something like Slonik you don't use escape characters, it does it transparently for you by taking advantage of JavaScript's string template literals.