|
|
|
|
|
|
by dicytea
636 days ago
|
|
|
> sqlx+sea-query (or sqlx+sea-orm) 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. > There was also pretty bad security issue That sounds concerning, can you link it here? |
|
|
> last time I touched [...] quite a while ago
it didn't exist back then ;=)
> That sounds concerning, can you link it here?
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.