[sampullman]

I use SQLx, but I'm not totally convinced it's better than writing raw SQL with the underlying postgres/sqlite3/mysql driver. The macros and typing fall apart as soon as you need anything more complicated than basic a SELECT with one to one relationships, much less one/many to many.

I remember fighting with handling enums in relations for a while, and now just default to manually mapping everything.

[echelon]

SQLx can handle complicated queries as long as they're completely static strings. We've got SELECT FOR UPDATE, upserts, and some crazy hundred-line queries that are fine with their macros.

SQLx sucks at dynamic queries. Dynamic predicates, WHERE IN clauses, etc.

For SQLx to be much more useful, their static type checker needs to figure out how to work against these. And it needs a better query builder DSL.

[sampullman]

Right, it's not bad if you stick with what the type checker can handle, but I usually end up falling back on manual building with the majority of queries in any semi-complex app.

It doesn't end up being too bad though, except for the loss of compile time syntax checking. Manually handling joins can be kind of nice, it's easier to see optimizations when everything is explicit.