[Blog] Edit

Author: tyt2y3

Blog/blog/2025-12-12-sea-orm-2.0.md

@@ -47,7 +47,17 @@ Simply remove `#[async_trait]` usage and it's Cargo dependency.
 
 Most `Send` and `Sync` in trait bounds can be removed.
 
-### 5. `BoxFuture`
+### 5. `Future`
+
+`impl Future<Output = T>` can be converted to just `T`.
+
+```rust
+// async
+fn exec<'a, C>(self, db: &'a C) -> impl Future<Output = Result<InsertResult<A>, DbErr>> + 'a;
+
+// sync
+fn exec<'a, C>(self, db: &'a C) -> Result<InsertResult<A>, DbErr>;
+```
 
 If you've used `BoxFuture` you can use the following shim:
 
@@ -121,9 +131,8 @@ The semantic difference in `lock()` between a synchronous mutex (`std::sync::Mut
 fn lock(&self) -> LockResult<MutexGuard<T>>
 ```
 
-+ Fallible: Returns a Result because the lock can be poisoned.
-
-+ Poisoning happens if a thread panics while holding the lock.
++ Fallible: Returns a Result because the lock can be poisoned
++ Poisoning happens if a thread panics while holding the lock
 
 #### `tokio::sync::Mutex::lock().await`
 
@@ -132,8 +141,7 @@ async fn lock(&self) -> MutexGuard<'_, T>
 ```
 
 + Infallible: always succeeds and returns a guard
-
-+ In async world mutexes don't get poisoned. A panic inside a task would abort the task, but would not affect other tasks. This is actually a problem in async Rust as a task can fail silently
++ In async world mutexes don't get poisoned. A panic inside a task would abort the task, but would not affect other tasks
 
 In practice, we did:
 
@@ -240,21 +248,22 @@ where
 
 ### 9. File / Network I/O
 
-This is very application specific. In SeaORM's case, the external I/O is handled by `rusqlite` and `sqlx` respectively. Their APIs differ significantly, that's why we have written `sea-query-sqlx` and `sea-query-rusqlite` to align them.
+This is very application specific. In SeaORM's case, the external I/O is handled by `sqlx` and `rusqlite` respectively. Their APIs differ significantly, that's why we have written `sea-query-sqlx` and `sea-query-rusqlite` to align their interfaces.
 
-For HTTP requests, you can simply use the sync and async versions of `Client` in different contexts.
+For HTTP requests, you can simply use the sync and async versions of `reqwest::Client` in different contexts.
 
 For file I/O, the API difference between sync and async Rust is very small.
 
 ## Conclusion: SQLite + SeaORM Sync = ⚡
 
 You can now use `sea-orm-sync` in CLI programs, and only bringing in small number of additional dependencies compared to having to bring in the async ecosystem.
 
-In fact, the compilation time speaks for itself. The async version of [quickstart](https://github.com/SeaQL/sea-orm/blob/master/examples/quickstart/src/main.rs) took 30 seconds to compile, while the [sync version](https://github.com/SeaQL/sea-orm/blob/master/sea-orm-sync/examples/quickstart/src/main.rs) only took 15 seconds!
+The compilation time speaks for itself. The async version of [quickstart](https://github.com/SeaQL/sea-orm/blob/master/examples/quickstart/src/main.rs) took 30 seconds to compile, while the [sync version](https://github.com/SeaQL/sea-orm/blob/master/sea-orm-sync/examples/quickstart/src/main.rs) only took 15 seconds!
 
-Right now only `rusqlite` is supported, but SeaORM's entire API surface is available. It's a breeze to add SQLite query capabilities to CLI programs where async would be overkill.
+Right now only `rusqlite` is supported, but SeaORM's entire API surface is available: including nested transactions. It's a breeze to add SQLite query capabilities to CLI programs where async would be overkill.
 
 ```rust
+// Same API as before
 let db = &sea_orm::Database::connect("sqlite::memory:")?;
 
 // Setup the database: create tables