Getting Started with Diesel (the TypeORM of Rust)

18 min read

Diesel is Rust’s most established ORM and query builder. If you reach for TypeORM, Prisma, or Sequelize in Node, Diesel is the closest cultural fit: you describe your tables, derive structs that map to rows, and build queries through a strongly typed DSL — except the mapping is checked by the Rust compiler instead of at runtime.

Quick Overview

Diesel maps SQL tables to Rust types and gives you a typed query builder, much like TypeORM maps tables to entity classes. The defining difference is that Diesel is synchronous and compile-time-checked: a query that selects the wrong column or loads into the wrong type is a build error, not a runtime exception. For a TypeScript developer the surprises are that there is no async/await here (Diesel uses a blocking connection you run on a thread or a blocking pool) and that the table definitions are generated for you by a CLI rather than declared with decorators.

Note: This file covers Diesel’s foundations — the table! schema, model structs, project setup, and the synchronous execution model. Building queries (filter/order/insert/update) lives in diesel-queries.md, and associations/joins live in diesel-relations.md. If you want async with hand-written SQL instead, start at sqlx-intro.md.

TypeScript/JavaScript Example

Here is a typical TypeORM setup: an entity class with decorators, a data source, and a couple of queries.

1
// TypeScript with TypeORM
2
import "reflect-metadata";
3
import {
4
  Entity,
5
  PrimaryGeneratedColumn,
6
  Column,
7
  DataSource,
8
} from "typeorm";
9

10
@Entity("users")
11
class User {
12
  @PrimaryGeneratedColumn()
13
  id!: number;
14

15
  @Column()
16
  name!: string;
17

18
  @Column({ unique: true })
19
  email!: string;
20

21
  @Column({ default: true })
22
  active!: boolean;
23
}
24

25
const dataSource = new DataSource({
26
  type: "postgres",
27
  url: process.env.DATABASE_URL,
28
  entities: [User],
29
  synchronize: true, // auto-creates tables in dev
30
});
31

32
async function main() {
33
  await dataSource.initialize();
34
  const repo = dataSource.getRepository(User);
35

36
  // Insert
37
  const user = repo.create({ name: "Ada Lovelace", email: "ada@example.com" });
38
  await repo.save(user); // user.id is now populated
39

40
  // Query
41
  const found = await repo.findOneBy({ id: user.id });
42
  console.log(found); // User { id: 1, name: 'Ada Lovelace', ... }
43

44
  const active = await repo.findBy({ active: true });
45
  console.log(`${active.length} active users`);
46
}
47

48
main();

Key points:

The entity class is the single source of truth; decorators describe the columns.
synchronize: true lets TypeORM create the schema from the entity (dev only).
Everything is async and returns a Promise.
A mistake like repo.findOneBy({ idx: 1 }) (typo in the column) is caught only when the query runs — TypeORM’s typings help, but raw query builders and find options leave plenty of runtime gaps.

Rust Equivalent

In Diesel the schema and the model are two separate things. A table! macro invocation (normally generated by the Diesel CLI into src/schema.rs) describes the table’s columns and SQL types. Your own struct then derives Queryable/Selectable/Insertable to map rows to and from that table.

1
// Rust with Diesel 2.3 + SQLite
2
use diesel::prelude::*;
3
use diesel::sqlite::SqliteConnection;
4

5
// Normally generated by `diesel print-schema` into src/schema.rs.
6
// You do NOT hand-write or hand-edit this in a real project.
7
diesel::table! {
8
    users (id) {
9
        id -> Integer,
10
        name -> Text,
11
        email -> Text,
12
        active -> Bool,
13
    }
14
}
15

16
// A row you read OUT of the database.
17
#[derive(Queryable, Selectable, Debug)]
18
#[diesel(table_name = users)]
19
#[diesel(check_for_backend(diesel::sqlite::Sqlite))]
20
struct User {
21
    id: i32,
22
    name: String,
23
    email: String,
24
    active: bool,
25
}
26

27
// A row you write INTO the database. No `id`: the database assigns it.
28
#[derive(Insertable)]
29
#[diesel(table_name = users)]
30
struct NewUser<'a> {
31
    name: &'a str,
32
    email: &'a str,
33
    active: bool,
34
}
35

36
fn main() -> Result<(), Box<dyn std::error::Error>> {
37
    // In-memory SQLite so this example is fully self-contained.
38
    let mut conn = SqliteConnection::establish(":memory:")?;
39

40
    // A migration normally creates the table; we do it inline here.
41
    diesel::sql_query(
42
        "CREATE TABLE users (\
43
            id INTEGER PRIMARY KEY AUTOINCREMENT, \
44
            name TEXT NOT NULL, \
45
            email TEXT NOT NULL, \
46
            active BOOLEAN NOT NULL DEFAULT 1)",
47
    )
48
    .execute(&mut conn)?;
49

50
    // Insert and get the full row back (id included).
51
    let new_user = NewUser {
52
        name: "Ada Lovelace",
53
        email: "ada@example.com",
54
        active: true,
55
    };
56
    let inserted: User = diesel::insert_into(users::table)
57
        .values(&new_user)
58
        .returning(User::as_returning())
59
        .get_result(&mut conn)?;
60
    println!("Inserted: {inserted:?}");
61

62
    // Load every row.
63
    let all: Vec<User> = users::table
64
        .select(User::as_select())
65
        .load(&mut conn)?;
66
    println!("All users: {all:?}");
67

68
    Ok(())
69
}

This compiles and runs with the following dependencies. SQLite needs no server, so it is the easiest backend for trying Diesel locally:

1
[dependencies]
2
diesel = { version = "2.3", features = ["sqlite", "returning_clauses_for_sqlite_3_35"] }
3
# Bundles SQLite so you do not need a system library installed:
4
libsqlite3-sys = { version = "0.37", features = ["bundled"] }

Real program output:

1
Inserted: User { id: 1, name: "Ada Lovelace", email: "ada@example.com", active: true }
2
All users: [User { id: 1, name: "Ada Lovelace", email: "ada@example.com", active: true }]

Note: diesel::table! and diesel::table! { ... } are the same macro. Generated schema.rs files typically use diesel::prelude::*; and write it as a bare table!. This guide writes diesel::table! so each snippet is copy-paste complete.

Detailed Explanation

`table!` describes the SQL table; it is generated, not authored

The table! macro is the heart of Diesel. It does not create a table in the database — it produces Rust types that describe a table that already exists. Each line like name -> Text introduces a column object (users::name) carrying its SQL type (diesel::sql_types::Text). The whole invocation also produces users::table (the table itself) and a users::dsl module for terse queries.

In TypeORM the entity class is both the schema description and the runtime model. In Diesel these are deliberately split:

schema.rs (the table! output) is the description of what the database actually looks like.
Your structs are the Rust-side view of rows, and you can have several per table.

You keep schema.rs in sync with the database by running diesel print-schema (or letting diesel migration run regenerate it). You do not edit it by hand, just as you would not hand-edit a Prisma-generated client.

Model structs and their derives

The #[derive(...)] list on a struct is where the mapping happens. The common derives:

Derive	Purpose	TypeORM analogy
`Queryable`	Build the struct from a result row (read side)	The shape returned by `repo.find...`
`Selectable`	Generate a `SELECT` list matching the struct fields	Choosing which columns to fetch
`Insertable`	Turn the struct into an `INSERT` (write side)	`repo.create(...)` / `repo.save(...)`
`AsChangeset`	Turn the struct into an `UPDATE SET ...` (covered in diesel-queries.md)	`repo.update(...)`

#[diesel(table_name = users)] ties the struct to the table! you defined. #[diesel(check_for_backend(diesel::sqlite::Sqlite))] asks Diesel to verify, at compile time, that every field’s Rust type can actually be read from that column’s SQL type on that backend. This is the line that turns a column/type mismatch into a build error.

User::as_returning() and User::as_select() come from Selectable. They produce a select list (id, name, email, active) that is guaranteed to match the struct’s fields and order, so you never have to keep a hand-written column list in sync with the struct.

Read model vs. write model

Notice there are two structs: User (read) and NewUser (write). The write model omits id because the database generates it. This pattern is idiomatic Diesel and maps cleanly to TypeORM’s distinction between a saved entity and the partial object you pass to repo.create(). NewUser<'a> borrows its strings (&'a str) so inserting does not require cloning your input data.

The synchronous model: there is no `await`

This is the biggest mental shift for a Node developer. establish, execute, load, and get_result are blocking calls. They return Result<T, diesel::result::Error> directly, not a Future. There is no async, no .await, and no runtime required for the example above.

In an async web server (for example an Axum handler — see Section 16), a blocking Diesel call would stall the async runtime’s worker thread. The standard fix is to run Diesel on a dedicated blocking pool (tokio::task::spawn_blocking with an r2d2 connection pool, covered in connection-pooling.md). If you would rather stay fully async, that is exactly what SQLx and the diesel-async crate are for.

Tip: Diesel returning a plain Result rather than a Future is the same “lazy vs. eager, runtime-or-not” theme from Section 11: Async: synchronous code needs no executor, so the entry point is an ordinary fn main, not an async one.

Key Differences

Aspect	TypeORM / Prisma (TypeScript)	Diesel (Rust)
Schema source of truth	Entity class / `schema.prisma`	Database migrations → generated `schema.rs`
Model definition	One class with decorators	`table!` (generated) + your own derived structs
Column/type errors	Mostly runtime; partial compile help	Compile-time error via `check_for_backend`
Concurrency model	`async`/`await`, returns `Promise`	Synchronous, returns `Result` (no runtime)
Auto-create schema	`synchronize: true`	Explicit migrations (`diesel migration run`)
Generics at runtime	Erased; reflection via `reflect-metadata`	Monomorphized; no reflection, all static
Query mistakes (typos)	Often surface as runtime SQL errors	Will not compile if the column/type is wrong

Why this design

Diesel’s whole premise is to push as many SQL mistakes as possible into the compiler. Because users::email is a distinct Rust type carrying Text, comparing it to an integer or loading it into an i32 simply has no valid trait implementation, so the program does not build. TypeORM cannot do this: TypeScript types are erased at runtime (see Section 09), so the ORM relies on decorators and runtime checks. Diesel trades the convenience of synchronize: true and a single entity file for the guarantee that a green build means your column mappings are sound.

Common Pitfalls

Pitfall 1: Mismatching a field’s Rust type and the column’s SQL type

This is the mistake check_for_backend exists to catch. Declaring id: String when the column is Integer:

1
// does not compile (error[E0277]): id is String but the column is Integer
2
#[derive(Queryable, Selectable)]
3
#[diesel(table_name = users)]
4
#[diesel(check_for_backend(diesel::sqlite::Sqlite))]
5
struct User {
6
    id: String, // wrong: the `id` column is Integer
7
    name: String,
8
    email: String,
9
    active: bool,
10
}

The real compiler error (trimmed for brevity — Diesel also prints a help: list of the SQL types String can be read from):

1
error[E0277]: the trait bound `String: FromSqlRow<diesel::sql_types::Integer, Sqlite>` is not satisfied
2
  --> src/main.rs:17:9
3
   |
4
13 | #[derive(Queryable, Selectable)]
5
   |                     ---------- in this derive macro expansion
6
...
7
17 |     id: String, // wrong: the `id` column is Integer
8
   |         ^^^^^^ the trait `FromSql<diesel::sql_types::Integer, Sqlite>` is not implemented for `String`
9
   |
10
   = note: double check your type mappings via the documentation of `diesel::sql_types::Integer`
11
   ...
12
   = note: required for `String` to implement `diesel::Queryable<diesel::sql_types::Integer, Sqlite>`
13
   = note: required for `String` to implement `FromSqlRow<diesel::sql_types::Integer, Sqlite>`

In TypeORM the equivalent typo compiles and blows up at runtime. Read the trait-bound message as “this Rust type cannot be read from this column type” and check your table! vs. struct mapping.

Pitfall 2: Forgetting the prelude or the `RunQueryDsl` methods

.execute(), .load(), .get_result(), and .first() are trait methods. If you forget use diesel::prelude::*; you get a “method not found” error even though the code looks right. The prelude re-exports RunQueryDsl, QueryDsl, SelectableHelper (for as_select/as_returning), and Connection. Import it once at the top of every module that talks to the database.

Pitfall 3: Expecting async / `.await`

1
// does not compile: establish() returns a Result, not a Future.
2
// let conn = SqliteConnection::establish(":memory:").await?;

Diesel is synchronous. There is nothing to .await. If you write .await on a Diesel call you will get an error that the value is not a Future. For async code, run Diesel via spawn_blocking (see connection-pooling.md) or use SQLx / diesel-async.

Pitfall 4: Treating `first()` like `findOneBy` returning `null`

repo.findOneBy() in TypeORM resolves to null when nothing matches. Diesel’s .first()/.get_result() instead return Err(diesel::result::Error::NotFound) when there is no row. To get TypeScript-like “maybe a row” behavior, call .optional(), which converts NotFound into Ok(None):

1
use diesel::prelude::*;
2
// (inside a function with `conn: &mut SqliteConnection` and the `users` table in scope)
3
// Returns Option<User>: Some(user) or None, never an Err for "not found".
4
// let maybe_user: Option<User> = users::table
5
//     .find(42)
6
//     .select(User::as_select())
7
//     .first(conn)
8
//     .optional()?;

Warning: Do not ignore the Result from a Diesel call. Unlike a rejected Promise that you might forget to await, a Rust Result you never inspect triggers a must_use warning — but only ? or a match actually handles the error. See Section 08: Error Handling.

Best Practices

Let the CLI own schema.rs. Install the CLI with cargo install diesel_cli --no-default-features --features sqlite (swap sqlite for postgres/mysql as needed) and regenerate the schema from migrations rather than editing it. Treat it like Prisma’s generated client.
Always add #[diesel(check_for_backend(...))] to Queryable/Selectable structs. It is the line that turns silent mapping bugs into compile errors; skipping it gives back the runtime-surprise behavior you came to Rust to avoid.
Keep separate read and write models. A Queryable User and an Insertable NewUser keep id/created_at out of inserts and make your intent explicit.
Prefer Selectable + as_select() over relying on column order. It frees you from manually matching the SELECT list to the struct and survives schema reordering.
Pick the SQLite backend with the bundled feature for examples and tests. libsqlite3-sys with features = ["bundled"] means no system SQLite install, and :memory: databases make tests hermetic.
Run blocking calls off the async runtime. In an Axum/Tokio app, wrap Diesel work in spawn_blocking and use an r2d2 pool (enable the r2d2 feature). Details in connection-pooling.md.

Real-World Example

A small user-store module that resembles a repository layer you might build behind a web handler. It creates the schema, inserts a couple of users, fetches one by primary key, and counts the active ones. It is fully self-contained on SQLite and prints real values.

1
// Cargo.toml:
2
// [dependencies]
3
// diesel = { version = "2.3", features = ["sqlite", "returning_clauses_for_sqlite_3_35"] }
4
// libsqlite3-sys = { version = "0.37", features = ["bundled"] }
5

6
use diesel::prelude::*;
7
use diesel::sqlite::SqliteConnection;
8

9
diesel::table! {
10
    users (id) {
11
        id -> Integer,
12
        name -> Text,
13
        email -> Text,
14
        active -> Bool,
15
    }
16
}
17

18
#[derive(Queryable, Selectable, Debug)]
19
#[diesel(table_name = users)]
20
#[diesel(check_for_backend(diesel::sqlite::Sqlite))]
21
struct User {
22
    id: i32,
23
    name: String,
24
    email: String,
25
    active: bool,
26
}
27

28
#[derive(Insertable)]
29
#[diesel(table_name = users)]
30
struct NewUser<'a> {
31
    name: &'a str,
32
    email: &'a str,
33
    active: bool,
34
}
35

36
/// Create the schema. A real app uses a migration instead (see migrations.md).
37
fn create_schema(conn: &mut SqliteConnection) -> QueryResult<usize> {
38
    diesel::sql_query(
39
        "CREATE TABLE users (\
40
            id INTEGER PRIMARY KEY AUTOINCREMENT, \
41
            name TEXT NOT NULL, \
42
            email TEXT NOT NULL, \
43
            active BOOLEAN NOT NULL DEFAULT 1)",
44
    )
45
    .execute(conn)
46
}
47

48
fn insert_user(conn: &mut SqliteConnection, new: &NewUser) -> QueryResult<usize> {
49
    diesel::insert_into(users::table).values(new).execute(conn)
50
}
51

52
/// TypeORM's `findOneBy({ id })`, but "not found" is a real None.
53
fn find_user(conn: &mut SqliteConnection, user_id: i32) -> QueryResult<Option<User>> {
54
    users::table
55
        .find(user_id)
56
        .select(User::as_select())
57
        .first(conn)
58
        .optional()
59
}
60

61
fn count_active(conn: &mut SqliteConnection) -> QueryResult<i64> {
62
    users::table
63
        .filter(users::active.eq(true))
64
        .count()
65
        .get_result(conn)
66
}
67

68
fn main() -> Result<(), Box<dyn std::error::Error>> {
69
    let mut conn = SqliteConnection::establish(":memory:")?;
70
    create_schema(&mut conn)?;
71

72
    insert_user(&mut conn, &NewUser { name: "Ada", email: "ada@x.com", active: true })?;
73
    insert_user(&mut conn, &NewUser { name: "Alan", email: "alan@x.com", active: false })?;
74

75
    match find_user(&mut conn, 1)? {
76
        Some(user) => println!("Found: {} <{}>", user.name, user.email),
77
        None => println!("No user with that id"),
78
    }
79

80
    println!("Missing user: {:?}", find_user(&mut conn, 999)?);
81
    println!("Active users: {}", count_active(&mut conn)?);
82

83
    Ok(())
84
}

Real program output:

1
Found: Ada <ada@x.com>
2
Missing user: None
3
Active users: 1

Each function returns QueryResult<T> (an alias for Result<T, diesel::result::Error>), so callers propagate failures with ? — the same composable error story as the rest of your Rust code, and unlike TypeORM where the database error type is opaque and easy to swallow.

Exercises

Exercise 1: Add a column and keep the mapping honest

Difficulty: Beginner

Objective: Practice keeping a table! definition and a model struct in agreement.

Instructions: Starting from the users table in this file, add a bio column of SQL type Text to the table! and a matching field to the User struct. Then deliberately give the new field the wrong Rust type (for example bool) and observe the compile error. Fix it so the program builds.

Solution

1
use diesel::prelude::*;
2
use diesel::sqlite::SqliteConnection;
3

4
diesel::table! {
5
    users (id) {
6
        id -> Integer,
7
        name -> Text,
8
        email -> Text,
9
        active -> Bool,
10
        bio -> Text, // added
11
    }
12
}
13

14
#[derive(Queryable, Selectable, Debug)]
15
#[diesel(table_name = users)]
16
#[diesel(check_for_backend(diesel::sqlite::Sqlite))]
17
struct User {
18
    id: i32,
19
    name: String,
20
    email: String,
21
    active: bool,
22
    bio: String, // matches `Text`. (Using `bool` here fails to compile, like Pitfall 1.)
23
}
24

25
fn main() -> Result<(), Box<dyn std::error::Error>> {
26
    let mut conn = SqliteConnection::establish(":memory:")?;
27
    diesel::sql_query(
28
        "CREATE TABLE users (\
29
            id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL, \
30
            email TEXT NOT NULL, active BOOLEAN NOT NULL DEFAULT 1, \
31
            bio TEXT NOT NULL DEFAULT '')",
32
    )
33
    .execute(&mut conn)?;
34

35
    let all: Vec<User> = users::table.select(User::as_select()).load(&mut conn)?;
36
    println!("{} users", all.len()); // prints: 0 users
37
    Ok(())
38
}

The compiler rejects bio: bool with the same FromSql<Text, Sqlite> is not implemented for bool family of errors shown in Pitfall 1; switching it to String makes it build.

Exercise 2: A separate write model

Difficulty: Intermediate

Objective: Build an Insertable write model and round-trip a row.

Instructions: Define a NewUser struct (no id) deriving Insertable, insert it, then load all users and print them. Use RETURNING so the insert hands you back the full User with its generated id.

Solution

1
use diesel::prelude::*;
2
use diesel::sqlite::SqliteConnection;
3

4
diesel::table! {
5
    users (id) {
6
        id -> Integer,
7
        name -> Text,
8
        email -> Text,
9
        active -> Bool,
10
    }
11
}
12

13
#[derive(Queryable, Selectable, Debug)]
14
#[diesel(table_name = users)]
15
#[diesel(check_for_backend(diesel::sqlite::Sqlite))]
16
struct User {
17
    id: i32,
18
    name: String,
19
    email: String,
20
    active: bool,
21
}
22

23
#[derive(Insertable)]
24
#[diesel(table_name = users)]
25
struct NewUser<'a> {
26
    name: &'a str,
27
    email: &'a str,
28
    active: bool,
29
}
30

31
fn main() -> Result<(), Box<dyn std::error::Error>> {
32
    let mut conn = SqliteConnection::establish(":memory:")?;
33
    diesel::sql_query(
34
        "CREATE TABLE users (id INTEGER PRIMARY KEY AUTOINCREMENT, \
35
         name TEXT NOT NULL, email TEXT NOT NULL, active BOOLEAN NOT NULL DEFAULT 1)",
36
    )
37
    .execute(&mut conn)?;
38

39
    let inserted: User = diesel::insert_into(users::table)
40
        .values(&NewUser { name: "Grace", email: "grace@x.com", active: true })
41
        .returning(User::as_returning())
42
        .get_result(&mut conn)?;
43
    println!("Inserted id={}", inserted.id); // Inserted id=1
44

45
    let all: Vec<User> = users::table.select(User::as_select()).load(&mut conn)?;
46
    println!("{all:?}");
47
    Ok(())
48
}

The insert requires the returning_clauses_for_sqlite_3_35 feature on the diesel dependency, which is shown in the Cargo.toml above.

Exercise 3: TypeORM’s `findOneBy` with honest absence

Difficulty: Intermediate

Objective: Reproduce repo.findOneBy({ id }) returning a nullable result, using Diesel’s Result/Option model.

Instructions: Write fn find_user(conn: &mut SqliteConnection, id: i32) -> QueryResult<Option<User>> that returns Ok(Some(user)) when the row exists and Ok(None) when it does not — never an Err for the “missing” case. Call it for both an existing and a non-existing id.

Solution

1
use diesel::prelude::*;
2
use diesel::sqlite::SqliteConnection;
3

4
diesel::table! {
5
    users (id) { id -> Integer, name -> Text, email -> Text, active -> Bool, }
6
}
7

8
#[derive(Queryable, Selectable, Debug)]
9
#[diesel(table_name = users)]
10
#[diesel(check_for_backend(diesel::sqlite::Sqlite))]
11
struct User {
12
    id: i32,
13
    name: String,
14
    email: String,
15
    active: bool,
16
}
17

18
fn find_user(conn: &mut SqliteConnection, id: i32) -> QueryResult<Option<User>> {
19
    users::table
20
        .find(id)
21
        .select(User::as_select())
22
        .first(conn)
23
        .optional() // turns Err(NotFound) into Ok(None)
24
}
25

26
fn main() -> Result<(), Box<dyn std::error::Error>> {
27
    let mut conn = SqliteConnection::establish(":memory:")?;
28
    diesel::sql_query(
29
        "CREATE TABLE users (id INTEGER PRIMARY KEY AUTOINCREMENT, \
30
         name TEXT NOT NULL, email TEXT NOT NULL, active BOOLEAN NOT NULL DEFAULT 1)",
31
    )
32
    .execute(&mut conn)?;
33
    diesel::sql_query("INSERT INTO users (name, email) VALUES ('Edsger', 'e@x.com')")
34
        .execute(&mut conn)?;
35

36
    println!("{:?}", find_user(&mut conn, 1)?.map(|u| u.name)); // Some("Edsger")
37
    println!("{:?}", find_user(&mut conn, 999)?.map(|u| u.name)); // None
38
    Ok(())
39
}

The key is .optional(): without it, find(999) would return Err(Error::NotFound) and propagate out of the function, which is rarely what a lookup-by-id helper should do.

Getting Started with Diesel (the TypeORM of Rust)

Quick Overview

TypeScript/JavaScript Example

Rust Equivalent

Detailed Explanation

table! describes the SQL table; it is generated, not authored

Model structs and their derives

Read model vs. write model

The synchronous model: there is no await

Key Differences

Why this design

Common Pitfalls

Pitfall 1: Mismatching a field’s Rust type and the column’s SQL type

Pitfall 2: Forgetting the prelude or the RunQueryDsl methods

Pitfall 3: Expecting async / .await

Pitfall 4: Treating first() like findOneBy returning null

Best Practices

Real-World Example

Further Reading

Exercises

Exercise 1: Add a column and keep the mapping honest

Exercise 2: A separate write model

Exercise 3: TypeORM’s findOneBy with honest absence

`table!` describes the SQL table; it is generated, not authored

The synchronous model: there is no `await`

Pitfall 2: Forgetting the prelude or the `RunQueryDsl` methods

Pitfall 3: Expecting async / `.await`

Pitfall 4: Treating `first()` like `findOneBy` returning `null`

Exercise 3: TypeORM’s `findOneBy` with honest absence