4 ms·
Sea ORM is too opinionated in my experience. Even making migration is not trivial with their own DSL. Diesel was ok, but I never use it anymore since rocket m
by karunamurti 2y ago
Sea ORM is too opinionated in my experience. Even making migration is not trivial with their own DSL.
Diesel was ok, but I never use it anymore since rocket moved to async.
I'm mainly use sqlx, it's simple to use, there's query! and query_as! macro which is good enough for most of the case.
- sverro2 2y agoI like sqlx, but have been eyeing diesel for some time. Any reasons you don't use diesel_async?
- malodyets 2y agoWith Diesel async integrating everything with the pooling is a bit hairy. With sqlx everything just works.
- sampullman 2y agoI 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 2y agoSQLx 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 2y agoRight, 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.