diesel VS sea-orm

Tauri's backend is in Rust, so I always thought the only way to use sqlite ORM in a Tauri app is with projects like diesel or prisma-client-rust, which could be hard because they are in rust. What is even harder is sqlite db encryption. Both of the 2 ORMs don't support cipher encryption, thus I had to write raw sql queries in kunkun Example Maintaining raw sql queries is a nightmare to me, especially when it comes to schema migration. I have to rely on thorough testing to make sure everything is correct. There is no type checking.

I think you are talking past each others. Preventing N+1 by doing lazy fetching and having synchronous / asynchronous API are orthogonal issues. Async API must not block the thread/event loop when the data loading is being done.

Diesel hasn't been providing an async API for reason told in this thread: https://github.com/diesel-rs/diesel/issues/399

The situation might change some day though, once async support in the core language and surrounding ecosystem gets stronger.

I would kinda expect REST framework to be able to generate Swagger (aka OpenAPI) definitions out of the box. That's one of the killer features if FastAPI in my opinion.

Also, I don't really understand what is the reason for creating your own ORM instead of integrating with, let's say diesel.rs [0] and what is the reason for inventing your own template language instead of just picking own of the most popular existing template engines [1].

Other than that this project looks really interesting and I will definitely keep an eye on it.

[0] https://diesel.rs/

[1] https://crates.io/categories/template-engine

> 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.

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

Diesel has support for MySQL, Sqlite and Postgres which can easily execute raw queries

https://github.com/diesel-rs/diesel

Here is another thing worth sharing. Database integration tests on Bazel used to be difficult. Ultimately I've found an elegant solution:

https://github.com/diesel-rs/diesel/blob/master/examples/pos...

The parallel testing with dangling transactions isn't Diesel or Postgres specific. You can do the same with pure SQL and any relational DB that supports transactions.

For CI, BuildBuddy can spin up Docker in a remote execution host, then you write a custom util that tests if the DB container is already running and if not starts one, out that in a test and then let Bazel execute all integration tests in parallel. For some weird reasons, all tests have to be in one file per insolated remote execution host, so I created one per table.

Incremental builds that compile, tests, build and publish images usually complete in about one minute. That's thanks to the 80 Core BuildBuddy cluster with remote cache.

GitHub took about an hour back in April when the repo was half in size.

There is real gain in terms of developer velocity.

7. Diesel

Both seem nice. However, both of them rely very heavily on prepared statements. Unfortunately, using prepared statements is a no-go when you use connection poolers like pgbouncer, or in my case AWS RDS proxy. A discussion in Diesel indicates that disel is not going to provide any support for disabling prepared stements (https://github.com/diesel-rs/diesel/discussions/3575), and a discussion on sqlx hints that disabling prepared statements is possible, but I haven't found any documentation or examples for it.

In addition we are experimenting with prebuild versions of diesel-cli that can be installed directly. We have a set of prebuilt binaries here. We are interested in feedback about how the provided binaries work on your platform.

First of all thanks for making this great tool. As it happens I currently toy around with using it for diesel-cli releases. See the WIP PR here. I think diesel-cli is a good example of a tool that depends on system libraries as it needs to link native database drivers, so this new release is welcome. Defining the dependencies seems to allow easily building things on x86_64-unknown-linux-gnu and x86_64-apple-darwin. It seems to pick up everything in the right way there.

SQL with SeaORM:

Haven't used it myself, but https://github.com/SeaQL/sea-orm seems to be popular in some communities and async

sea-orm

SeaORM has an Actix example in their GitHub. https://github.com/SeaQL/sea-orm/tree/master/examples/actix_example

SeaORM or the underlying SQLx query builder for SQL handling.

SeaORM is the most advanced ORM currently available, but a lot of people prefer to just skip ORMing and go direct to the underlying SQLx query builder.

If you want to do backend development, give actix-web or Axum a try. If you need templating, take a look at Maud and if you want an ORM, take a look at SeaORM.

SeaORM is the most advanced option right now (though a lot of people prefer to go direct to the underlying SQLx library) but it doesn't yet match Django ORM for offering auto-generation of draft database migrations, which is one of the things I'm unwilling to regress on. (i.e. so all I need to hand-edit is stuff like "that's a rename, not a remove+add" and so on)

Last I checked, authentication was weak. SeaORM is probably the most mature option if you're looking for an ORM like you'd find in another ecosystem (if you're willing to explore alternative designs, try using the underlying SQLx directly).