> sqlx — a compile time, type safe SQL wrapper that runs your queries against a real DB
SQLx seems like end game stuff at first glance, but after trying it out for a while I eventually decided that it wasn't for me. Writing dynamic/conditional queries just sucks and there isn't any good solution. On the DX side, completion, formatting/linting, highlighting is also non-existent (at least on VS Code).
I eventually settled on [Diesel][0] (a query builder-ish ORM) and I'm loving it so far. Its [performance][1] crushes every other SQL libraries, including SQLx (very counter-intuitive, huh?). It's technically an ORM, but the query builder is very flexible and you can also extend it with your own traits. It got its warts, but it's the most tolerable SQL rust library I've found so far.
AFAIK diesel is not async. On top of that, I'm pretty sure you can find a query that you won't be able to perform with diesel DSL (some obscure PostgreSQL syntax). What I like about sqlx is that it's just pure SQL.
diesel-async works fine for almost all use-cases, it just layers over standard diesel calls via importing an async `RunQueryDsl` trait. I almost never think about it.
> Writing dynamic/conditional queries just sucks and there isn't any good solution.
SQLx is just providing some "core" foundations, which means yes there is no good query builder or anything like that.
So if you want to compare SQLx with e.g. Diesel it's a bit comparing apple to apple trees, instead comparing sqlx+sea-query (or sqlx+sea-orm) would be a better comparison (through sqa-orm again isn't a fully even comparison as it goes ins some points further then what diesel provides).
Idk. about now but last time I touched diesel (quire a while ago) I found their query building catastrophically bad the moment the query isn't build all in one place, productivity also wasn't good with it. There was also pretty bad security issue they handled IMHO catastrophically convincing me to stay away from it. Through I guess a lot of things probably got much better since then.
I tried sea-orm, but I find its ORM API way too limited (it can't even do multiple joins). For anything beyond simple queries, you end up needing to use its query builder (sea-query) which is blind to your db schema so you need to manually hand-validate all your queries. It's basically no better than pushing string queries + manually validating the output with serde.
> I found their query building catastrophically bad the moment the query isn't build all in one place
If you're talking about its crazy return types, there's the auto_type macro that lets you generate return types for functions automatically.
It shouldn't be there anymore the issue was mainly the way it was handled. I had removed the details as it was too long in the past to reliably remember all details. Through it was something along of the lines of: Transactions in case of a panic not getting reset and getting reused if you used the connection pool they reexported (which depending what you do, e.g. if you have row-level security policies, can be very bad). And when that was reported some other issues with the pool where found related to UnwindSafe (1). The pool fixed that issues and if it would have ended there everything would have been fine. The issue is the diesel authors didn't update to the newer version of the pool (which they reexported!) because they didn't like the whey the fix was done due to some resons I don't remember exactly but back then found found pedantic and unreasonable. Furthermore not only did they not adapt the fix (back then I guess they did by now), they also didn't deprecate the pool, didn't replace it with a different one , closed all issues with the vulnerability, didn't document it and criticized everyone opening the issue after having run into it for not "checking closed issues for very much still existing/open security vulnerability". But again that was years ago so whatever things might be much better by now and the developers might very well have learned to properly handle security issues by now.
(1): As a side note IMHO UnwindSafe is one of the worst design mistakes in rust as it uses the term "safe" but has nothing to do with "unsafe" or soundness. Every rust type has to be "safe" i.e. sound in context of crossing unwind boundaries. `UnwindSafe` just indicates if it will "behave reasonable" in such a context. E.g. a non `UnwindSafe` type might panic or outright abort if used after unwinding (but it still has to stay sound!). The reason I'm mentioning it is because back then diesel seemed to have been (as far as I could tell) designed with the mindset that if you don't use panic=abort it's your problem if you have bugs. Again that might very well have changed by now, or at least be well documented by now, but it wasn't back then.
just to be really clear about it all that happened multiple years ago do not judge them on how they managed their project in the past but how they manage it now
SQLx seems like end game stuff at first glance, but after trying it out for a while I eventually decided that it wasn't for me. Writing dynamic/conditional queries just sucks and there isn't any good solution. On the DX side, completion, formatting/linting, highlighting is also non-existent (at least on VS Code).
I eventually settled on [Diesel][0] (a query builder-ish ORM) and I'm loving it so far. Its [performance][1] crushes every other SQL libraries, including SQLx (very counter-intuitive, huh?). It's technically an ORM, but the query builder is very flexible and you can also extend it with your own traits. It got its warts, but it's the most tolerable SQL rust library I've found so far.
[0]: https://diesel.rs
[1]: https://github.com/diesel-rs/metrics