Hacker News Reader

Comment by echelon | Hacker News Reader

Good luck with this, Lucas! We need all of the innovation in the Rust DB space we can get.

I can't use yours in production yet as it only supports SQLite, but I'll keep my eyes peeled for updates.

We're using Sqlx and Diesel in production currently.

Sqlx is great because it's not an ORM and lets you write "type checked" raw SQL. It frustrates us in the fact that you can't write dynamic queries and have them be type checked, though. No `IN` clauses or conditional predicates, only static queries with simple bindings get type checked.

Love to see more ORMs like yours! Diesel isn't our favorite.

View on HN

My first Rust PR was for a Diesel Plugin crate, their macros weren't updated with Rusts newer spec.

I honestly really enjoyed Diesel but it's extremely slow migration to async really made it lose traction.

I've used SQLx extensively for projects after that and it was pretty decent.

Please note that up until today an async rust database library does not give you any measurable performance advantage compared to a sync database library. In addition to that it won't even matter for most applications as they don't reach the required scale to even hit that bottleneck. As a matter of facts crates.io just run well on sync diesel up until maybe a month ago. They have now switched to diesel-async, for certain specific not-performance related reasons. The lead developer there told me specifically that from a performance point of view the service would have been fine with sync diesel for quite a while without problems, and that's with somewhat exponential growth of requests.

Other than that the async rust ecosystem is still in a place that makes it literally impossible to provide strong guarantees around handling transactions and make sure that they ended, which is a main reason why diesel-async is not considered stable from my side yet. This problem exists in all other async rust database libraries as well, as it's an language level problem. They just do not document this correctly.

WEIZNICH! I am your biggest fan. Thank you so much for the amazing crates you've made and for Diesel.

When I started my rust journey Diesel and Rocket were the first few crates I worked with and it really opened up my mind and I haven't turned back since.

As for async, my primary concern for that was to make sure you minimise blocking code calls in your futures. Even if there weren't many performance gains to be made from Diesel itself being async but having database calls marked as Futures could theoretically help the runtime schedule and manage other threads.

I'd like to thank you for you amazing work once more!

> As for async, my primary concern for that was to make sure you minimise blocking code calls in your futures. Even if there weren't many performance gains to be made from Diesel itself being async but having database calls marked as Futures could theoretically help the runtime schedule and manage other threads.

That doesn't require an async database library at all. It merely requires some abstraction like [`deadpool-diesel`](https://docs.rs/deadpool-diesel/latest/deadpool_diesel/index...) that ensures that the caller always uses `tokio::spawn_blocking` or similar to run database queries. And yes this scales rather well as the number of database connections in your application is rather low (usually a few ten) and therefore much smaller than the number of threads in the tokio blocking thread-pool.

Depending on what database you're using, you might be able to restructure your dynamic queries to fit a static form...

WHERE ... AND CASE WHEN ? IS NULL THEN TRUE ELSE col ILIKE ? || '%' END AND CASE WHEN ? IS NULL THEN TRUE ELSE col2 IN (?) END

Each "dynamic" parameter is then bound twice. (My personal preference is to use a CTE to bind and name my parameter values in the query instead of binding multiple times whenever possible).

That only works when the dynamic portion is in the WHERE clause, though. I often need to dynamically generate UPDATEs and even sometimes INSERTs.

It doesn't even work for all dynamic where clauses, but only for such that can lead to a fixed number of combinations. This approach doesn't work for dynamic API's that let users combination column + filters as required, which is rather common in complex web applications. (Think of the GitHub issue search box for example)

After being frustrated with Diesel, I gave a try to SeaORM and I couldn’t be happier (have been using it for more than a year). It is not perfect but certainly the best ORM I have ever used myself (vs Diesel, ActiveRecord, SQLAlchemy)

How come? I’m new to the space and picked Diesel a couple weeks ago for a new project because it seemed the most recommended. What do you prefer about SeaORM?

To me, SeaORM feels like a well-designed library while many things in Diesel feel like an afterthought or a hack. Which mostly manifests itself when doing something complex and debugging it.

Also recommend reading https://www.sea-ql.org/SeaORM/docs/internal-design/diesel/

I’ll check it out. Thanks!

sea-query looks a lot like jOOQ!

Please note that this comparison is outdated since at least 2 years, given that diesel-async exists for more than 2 years now and this page completely forgets to mention it.

SeaORM is not compile time safe by their own admission so it's automatically out of the running, personally speaking.

That feels like a weird requirement to me; an ORM is by its very nature not going to be able to validate queries at compile-time.

And even if you're writing queries directly, any time you need to write something dynamic, you're not going to be able to verify those at compile-time either.

> an ORM is by its very nature not going to be able to validate queries at compile-time.

I don't see why this is by its "very nature" when libraries like diesel or Prisma already do this.

> any time you need to write something dynamic, you're not going to be able to verify those at compile-time either.

Diesel can validate dynamic queries at compile time too, sqlx too to some extent.

Reply on news.ycombinator.com