Update the "Compare with Diesel" page to include some more facts

[weiznich]

I would like to request that the "Compare with Diesel" page includes some more facts and that some inaccuracies are clarified:

Both SeaORM and Diesel works with MySQL, Postgres and SQLite, so you aren't constrained going with either.

Diesel also allows third parties to implement custom backends, which means there is support for more database "available". Public sources I'm aware of:

• [diesel-oci](Both SeaORM and Diesel works with MySQL, Postgres and SQLite, so you aren't constrained going with either.) (An oracle backend)
• rsfbclient (A firebird backend)
• This PR claiming they have a odbc based sqlserver backend.

While Diesel is tied to native drivers. Each side has their pros and cons, so it's up to your preference.

Diesel is not tied to any native drives. The default provided backends use the native driver internally but it's certainly possible (and feasible) to implement pure rust drivers. I would estimate that this needs as less than 300 lines of rust code.

Diesel has an everything-compile-time design which has its pros and cons.

I feel that this wording here is a bit to strict. Yes diesel provides an API that can be checked at compile time entirely. But it also provides utilities to write dynamic queries + [there are extension crates for fully dynamic queries].

Both libraries make heavy use of traits and generics, but SeaORM generate less types (each column in Diesel is a struct, while each column in SeaORM is a enum variant) and less depthness (there won't be A<B<C>>). That probably means looser type/lifetime constraints and faster compilation.

I would like to see numbers for those claims. I did a short possibly unscientific benchmark and got the following results. I basically did a minimal example with one table and one query:

Diesel from scratch: 21.5s (cargo +stable build)
Diesel no-change: 0.34s (touch src/main.rs + cargo +stable build)
diesel query add: 0.48s (add another query + cargo +stable build)

sea-orm from scratch: 1m 34s (cargo +stable build)
sea-orm no-change: 0.87s (touch src/main.rs + cargo +stable build)
sea-orm query add: 1.79s (add another query + cargo +stable build)

For all cases the compilation of the diesel based implementation is faster by at least a factor of 2.

We keep macros out of the API of SeaORM. We provide some derive macros for implementing traits, but it is possible to use SeaORM without macros.

I would say that's also true for diesel. (Maybe besides the table! macro.)

[tyt2y3]

Hi Diesel Team, welcome!

I know people would ask this frequently, so I tried to write one up as objectively as possible.
However, we are both biased to some degree I'd admit.
I guess I should invite some external author to rewrite this article later.

Sure, I will try to rework the statements without being too verbose.
As for performance claims, I do agree that having benchmarks are important.
And I'd say, we should find a moderately complex schema to compare against each other.

I may ask for clarification when I can think of some counter-arguments.
That's it for now, have a nice day!

[baoyachi]

@weiznich
Hi:what are the plans for supporting asynchrony in diesel.

[weiznich]

@tyt2y3 It's perfectly fine to be biased here. I do not find that this comparison is badly written or heavily biased. I would likely remove that claim about compilation times (at least as long as there are no hard numbers for this) and probably soften a few other formulations (like that one saying diesel is tied to native drives, which could just say that diesel uses the native drivers).

As for the benchmarks: Sure feel free to suggest something.

@baoyachi Yes there are plans for async support in diesel, but unfortunately doing "the right way" that would require fixes for a few bugs in rustc that are open for quite a long time now (Especially rust-lang/rust#59337). Additionally at least I have quite a few concerns about the stability, performance and maintainability of such an implementation. To just shorten this: I personally fail to see that async database connection itself are that important in rust, as database connections itself are generally a resource that will restrict the throughput (as it's running out of database connections). It's just you cannot open thousands of concurrent connections so your service will just wait on the availability of the connection, instead of the response from the server in most cases. That can be quite easily migrated by just using an async connection pool. (There are a few pool implementations out there that support diesel).
The performance concerns are my original motivation to write those benchmarks for diesel. I really would like to see that someone suggests some benchmark that actually shows some gain by async implementations, but so far that's not the case. Maybe I can work together with @tyt2y3 to get something going there.

[tyt2y3]

We keep macros out of the API of SeaORM. We provide some derive macros for implementing traits, but it is possible to use SeaORM without macros.

I would say that's also true for diesel. (Maybe besides the table! macro.)

@weiznich I always have puzzles about the allow_tables_to_appear_in_same_query and allow_columns_to_appear_in_same_group_by_clause macros.

It's like I always forget it, compile error, stack overflow and add it again. Can I use that as a counter-argument?

[weiznich]

allow_tables_to_appear_in_same_query is something you normally don't even have to border with, as this is generated by diesel cli as part of the schema definition. If you feel that this is nevertheless a huge problem in diesel API you can use that as argument, but at least for me that does not really sound like a good argument then. allow_columns_to_appear_in_same_group_by_clause is not yet part of a release yet, so I wouldn't really include it in any argument.

[mikaelmello]

I started to port my (very small) CLI app that uses SQLite as the back-end and there seems to be a lack of a main feature in my opinion: SeaORM is not able to generate entities from SQLIte databases, I receive a message saying "database not supported" and upon reading the code, it looks like only MySQL and PGSQL are supported.

Both SeaORM and Diesel works with MySQL, Postgres and SQLite, so you aren't constrained going with either.

With that in mind, the above phrase was highly misleading for me.

I would love to be proven wrong and find out that I missed how I could generate entities from SQLite.

[tyt2y3]

I started to port my (very small) CLI app that uses SQLite as the back-end and there seems to be a lack of a main feature in my opinion...

Yes. The utility is not able to generate entities from a SQLite database dump for now.

The recommend way is to go 'Model First', where you write the entity file by hand (or port from somewhere), and then use the create_table_from_entity method to setup a fresh database.

With that in mind, the above phrase was highly misleading for me.

Sorry if that confuses you. We are always trying to improve and expand the documentation. Will add some clarification soon.

[tyt2y3]

@weiznich

Diesel also allows third parties to implement custom backends, which means there is support for more database "available". Public sources I'm aware of

Added clarification

Diesel is not tied to any native drives. The default provided backends use the native driver internally but it's certainly possible (and feasible) to implement pure rust drivers. I would estimate that this needs as less than 300 lines of rust code.

Added clarification

Yes diesel provides an API that can be checked at compile time entirely. But it also provides utilities to write dynamic queries + [there are extension crates for fully dynamic queries].

Added clarification

I would like to see numbers for those claims.

Removed the statement. It was 'probably' as in 'probably the best beer in the world' anyway.

I would say that's also true for diesel. (Maybe besides the table! macro.)

Removed the statement.

Finally, I'd say, performance was not the selling point. The point is the programming paradigm, which, probably, at the end, do not have a strict better or worse.

Please close this issue if you are satisfied.

[weiznich]

Thanks for the update. I feel its much better now. 👍

Finally, I'd say, performance was not the selling point. The point is the programming paradigm, which, probably, at the end, do not have a strict better or worse.

Let me use this issue to thank you for your work here. I'm really happy to see some alternative to diesel emerging that explores a different design. I believe its important for the ecosystem to have more than one solution available for such complex crates. Especially if those solutions implement different design patterns, as there is no such thing like the "right" solution here.