Diesel Relations: Associations, Joins, and Eager Loading

17 min read

In TypeORM or Prisma you describe relations with decorators (@OneToMany, @ManyToOne) or a schema block, then include/relations pulls children in automatically. Diesel takes a more explicit, compile-checked approach: you declare which tables can be joined, derive Associations, and assemble parent/child trees yourself with belonging_to and grouped_by. This page shows how the belongs_to/has_many model maps onto Diesel and how to do eager loading without N+1 queries.

Quick Overview

A relational schema is mostly about foreign keys: a post belongs to an author, an author has many posts. TypeORM hides the wiring behind decorators and lazy proxies; Diesel keeps it explicit and type-safe. You declare joins once in your schema, derive Associations on your models, and load related rows either with SQL joins (inner_join/left_join) or with the association helpers (belonging_to + grouped_by) that let you fetch a whole parent/child tree in a fixed number of queries.

Note: Diesel is synchronous. The examples here run on a blocking connection, exactly as covered in diesel-intro.md. For async query execution, SQLx is the more natural fit — see sqlx-intro.md and the trade-offs in orm-comparison.md.

The examples below use the bundled SQLite backend so they run with no external database. The concepts are identical on PostgreSQL and MySQL.

1
cargo add diesel --features sqlite,returning_clauses_for_sqlite_3_35
2
cargo add libsqlite3-sys@0.37 --features bundled   # ships SQLite so no system lib is needed

The current stable toolchain is Rust 1.96.0 on the 2024 edition (cargo new selects it automatically); the code here was verified against Diesel 2.3.

TypeScript/JavaScript Example

Here is a typical blog schema with TypeORM. An Author has many Posts, and each Post has many Comments.

1
// entities.ts (TypeORM)
2
import {
3
  Entity,
4
  PrimaryGeneratedColumn,
5
  Column,
6
  OneToMany,
7
  ManyToOne,
8
} from "typeorm";
9

10
@Entity()
11
export class Author {
12
  @PrimaryGeneratedColumn() id!: number;
13
  @Column() name!: string;
14

15
  @OneToMany(() => Post, (post) => post.author)
16
  posts!: Post[];
17
}
18

19
@Entity()
20
export class Post {
21
  @PrimaryGeneratedColumn() id!: number;
22
  @Column() title!: string;
23

24
  @ManyToOne(() => Author, (author) => author.posts)
25
  author!: Author;
26

27
  @OneToMany(() => Comment, (comment) => comment.post)
28
  comments!: Comment[];
29
}
30

31
@Entity()
32
export class Comment {
33
  @PrimaryGeneratedColumn() id!: number;
34
  @Column() body!: string;
35

36
  @ManyToOne(() => Post, (post) => post.comments)
37
  post!: Post;
38
}

Loading related data is one method call. TypeORM generates the joins (or extra queries) for you:

1
// Eager-load every author together with their posts.
2
const authors = await dataSource.getRepository(Author).find({
3
  relations: { posts: true },
4
});
5

6
for (const author of authors) {
7
  console.log(`${author.name} has ${author.posts.length} post(s)`);
8
}
9

10
// A nested tree: authors -> posts -> comments
11
const tree = await dataSource.getRepository(Author).find({
12
  relations: { posts: { comments: true } },
13
});

This is convenient, but two costs are hidden:

The N+1 problem. With lazy relations (or a naive loop calling author.posts), one query per author is issued. TypeORM can do this silently.
No compile-time guarantee that posts.author actually maps to a real column; a typo in a relation name surfaces only at runtime.

Rust Equivalent

Diesel models are plain structs. You declare the foreign-key relationships in the schema (which diesel print-schema normally generates) and on the models, then assemble trees explicitly.

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

4
// Normally generated into schema.rs by `diesel print-schema`.
5
mod schema {
6
    diesel::table! {
7
        authors (id) { id -> Integer, name -> Text, }
8
    }
9
    diesel::table! {
10
        posts (id) { id -> Integer, author_id -> Integer, title -> Text, }
11
    }
12
    diesel::table! {
13
        comments (id) { id -> Integer, post_id -> Integer, body -> Text, }
14
    }
15

16
    // Declare the foreign-key join paths once.
17
    diesel::joinable!(posts -> authors (author_id));
18
    diesel::joinable!(comments -> posts (post_id));
19
    diesel::allow_tables_to_appear_in_same_query!(authors, posts, comments);
20
}
21

22
use schema::{authors, comments, posts};
23

24
#[derive(Queryable, Selectable, Identifiable, Debug, PartialEq)]
25
#[diesel(table_name = authors)]
26
#[diesel(check_for_backend(diesel::sqlite::Sqlite))]
27
struct Author {
28
    id: i32,
29
    name: String,
30
}
31

32
#[derive(Queryable, Selectable, Identifiable, Associations, Debug, PartialEq)]
33
#[diesel(belongs_to(Author))] // posts.author_id -> authors.id
34
#[diesel(table_name = posts)]
35
#[diesel(check_for_backend(diesel::sqlite::Sqlite))]
36
struct Post {
37
    id: i32,
38
    author_id: i32,
39
    title: String,
40
}
41

42
#[derive(Queryable, Selectable, Identifiable, Associations, Debug, PartialEq)]
43
#[diesel(belongs_to(Post))] // comments.post_id -> posts.id
44
#[diesel(table_name = comments)]
45
#[diesel(check_for_backend(diesel::sqlite::Sqlite))]
46
struct Comment {
47
    id: i32,
48
    post_id: i32,
49
    body: String,
50
}

Eager-loading every author with their posts in exactly two queries:

1
fn authors_with_posts(conn: &mut SqliteConnection) -> QueryResult<Vec<(Author, Vec<Post>)>> {
2
    // Query 1: load all authors.
3
    let all_authors = authors::table
4
        .select(Author::as_select())
5
        .load(conn)?;
6

7
    // Query 2: load every post belonging to any of those authors,
8
    // then bucket the posts under their parent author.
9
    let posts_per_author = Post::belonging_to(&all_authors)
10
        .select(Post::as_select())
11
        .load(conn)?
12
        .grouped_by(&all_authors);
13

14
    // Zip authors with their post buckets — no extra query.
15
    Ok(all_authors.into_iter().zip(posts_per_author).collect())
16
}

Calling it and printing the result produces this real output:

1
== eager-loaded authors with posts ==
2
  Ada has 2 post(s)
3
  Grace has 1 post(s)

Detailed Explanation

Declaring the relationship

Two declarations describe a belongs_to/has_many pair:

joinable!(posts -> authors (author_id)) in the schema tells Diesel that posts.author_id is the foreign key into authors.id. This is what makes SQL joins (inner_join, left_join) type-check.
#[diesel(belongs_to(Author))] on the Post model, paired with #[derive(Associations)], generates a BelongsTo<Author> impl. This is what powers Post::belonging_to(...).

By convention Diesel infers the foreign key as author_id (the parent’s snake-cased struct name + _id). If your column is named differently, spell it out: #[diesel(belongs_to(Author, foreign_key = writer_id))].

There is no has_many annotation. In Diesel, “an author has many posts” is just the inverse of “a post belongs to an author” — you express it by calling Post::belonging_to(&author). This is the opposite direction from TypeORM, where you decorate both sides.

Note: belonging_to requires the parent type to derive Identifiable (so Diesel knows the parent’s primary key). Forgetting it is a common error — see Common Pitfalls.

`belonging_to` for a single parent

1
let ada = authors::table
2
    .find(1)
3
    .select(Author::as_select())
4
    .first(conn)?;
5

6
let adas_posts = Post::belonging_to(&ada)
7
    .select(Post::as_select())
8
    .load(conn)?;

Post::belonging_to(&ada) builds a query equivalent to SELECT ... FROM posts WHERE posts.author_id = 1. It returns a normal query you can further .filter(), .order(), or .limit() just like any other Diesel query (see diesel-queries.md).

`belonging_to` for many parents + `grouped_by` (the eager-load pattern)

The key insight: belonging_to accepts a slice of parents, generating WHERE posts.author_id IN (...). You then call .grouped_by(&parents) on the loaded children. grouped_by returns a Vec<Vec<Child>> whose order matches the parent slice — bucket i holds the children of parent i, including empty buckets for parents with no children. A final zip stitches them together:

1
let authors = authors::table.select(Author::as_select()).load(conn)?;          // 1 query
2
let grouped = Post::belonging_to(&authors)                                     // 1 query
3
    .select(Post::as_select())
4
    .load(conn)?
5
    .grouped_by(&authors);
6
let result: Vec<(Author, Vec<Post>)> = authors.into_iter().zip(grouped).collect();

Two queries total, regardless of how many authors exist. This is Diesel’s answer to the N+1 problem: instead of one query per parent, you batch all children into a single IN (...) query and group them in memory.

SQL joins for flat rows

When you want flat tuples rather than a nested tree, use inner_join:

1
let rows: Vec<(Post, Author)> = posts::table
2
    .inner_join(authors::table)
3
    .select((Post::as_select(), Author::as_select()))
4
    .load(conn)?;
5

6
for (post, author) in &rows {
7
    println!("'{}' by {}", post.title, author.name);
8
}

Real output for the sample data:

1
== inner join (post -> author) ==
2
  'Rust ownership' by Ada
3
  'Lifetimes' by Ada
4
  'Borrow checker' by Grace

Diesel infers the ON posts.author_id = authors.id clause from the joinable! declaration, so you do not write it by hand. For an outer join, use left_join and select the right-hand side as Option<T>:

1
let rows: Vec<(Author, Option<Post>)> = authors::table
2
    .left_join(posts::table)
3
    .select((Author::as_select(), Option::<Post>::as_select()))
4
    .load(conn)?;

An author with no posts yields (author, None). This is the type system encoding the SQL fact that the right side of a left join may be null — far harder to forget than in TypeScript, where a missing row is just undefined.

Three-level eager loading

The same pattern nests. To build authors -> posts -> comments in three queries:

1
let authors = authors::table.select(Author::as_select()).load(conn)?;        // query 1
2
let posts = Post::belonging_to(&authors).select(Post::as_select()).load(conn)?; // query 2
3
let comments = Comment::belonging_to(&posts)                                  // query 3
4
    .select(Comment::as_select())
5
    .load(conn)?;
6

7
// Group bottom-up.
8
let comments_per_post = comments.grouped_by(&posts);
9
let posts_with_comments: Vec<(Post, Vec<Comment>)> =
10
    posts.into_iter().zip(comments_per_post).collect();
11
let grouped = posts_with_comments.grouped_by(&authors);
12
let tree: Vec<(Author, Vec<(Post, Vec<Comment>)>)> =
13
    authors.into_iter().zip(grouped).collect();

Note grouped_by works on (Post, Vec<Comment>) tuples too — it groups by the Post (the BelongsTo<Author> parent), carrying the attached comments along. Real output:

1
== three-level tree ==
2
  Ada:
3
    Rust ownership (2 comments)
4
    Lifetimes (0 comments)
5
  Grace:
6
    Borrow checker (1 comments)

Three round-trips for an arbitrarily large, fully nested tree — versus the N+1 explosion a naive loop would cause.

Key Differences

Concept	TypeScript (TypeORM/Prisma)	Rust (Diesel)
Declare a relation	`@OneToMany` / `@ManyToOne` decorators on both sides	`joinable!` + `belongs_to(Parent)` on the child only
`has_many`	Explicit `@OneToMany` field	Implicit: inverse of `belongs_to`, via `Child::belonging_to(&parent)`
Eager load	`find({ relations: { posts: true } })`	`belonging_to(&parents)` + `grouped_by` + `zip`
Join	Generated automatically; relation is a field	`inner_join` / `left_join`; result is a tuple `(A, B)`
Outer join null	`undefined` on the relation	`Option<Child>` enforced by the type system
Avoiding N+1	Up to you to remember `relations`/`include`	Built into the `belonging_to(&slice)` pattern
Wrong relation name	Runtime error	Compile error (`JoinTo` / `Identifiable` not implemented)
Lazy loading	Default in some configs (proxies)	Does not exist — loads are always explicit

The biggest mental shift: Diesel has no lazy-loaded relation fields. A Post struct has an author_id: i32, not an author: Author. You never accidentally trigger a query by touching a field — every database access is a visible .load()/.first() call. That removes a whole class of surprise N+1 queries that lazy ORMs are prone to, at the cost of a little more ceremony.

The second shift: relationships are directional and one-sided in the model. You annotate the child (belongs_to), and the parent’s “has many” is just a query against the child. There is nothing to keep in sync on the parent side.

Common Pitfalls

Forgetting `joinable!` / `allow_tables_to_appear_in_same_query!`

If you try to join two tables that Diesel does not know are related, you get a compile error — not a runtime surprise. Omitting joinable!(posts -> authors (author_id)) and writing posts::table.inner_join(authors::table) produces this real error:

1
error[E0277]: cannot join `authors::table` to `posts::table` due to missing relation
2
   --> src/main.rs:27:21
3
    |
4
    |          ---------- ^^^^^^^^^^^^^^ the trait `JoinTo<authors::table>` is not implemented for `posts::table`

A second error points right at the fix:

1
error[E0277]: the trait bound `posts::table: TableNotEqual<authors::table>` is not satisfied
2
   = note: double check that `authors::table` and `posts::table` appear in the same `allow_tables_to_appear_in_same_query!`

Fix: add both joinable!(posts -> authors (author_id)) and list the tables in allow_tables_to_appear_in_same_query!. When diesel print-schema generates your schema.rs from a database with real foreign-key constraints, it writes these for you.

Forgetting `Identifiable` (or `Associations`) for `belonging_to`

belonging_to is provided by the association machinery and needs the parent to derive Identifiable and the child to derive Associations. If the parent Author derives only Queryable, Selectable, calling Post::belonging_to(&author) fails to compile with this real error:

1
error[E0599]: no function or associated item named `belonging_to` found for struct `Post` in the current scope
2
   --> src/main.rs:28:19
3
   = help: items from traits can only be used if the trait is implemented and in scope

Fix: derive Identifiable on the parent and Associations (plus Identifiable) on the child, and add #[diesel(belongs_to(Parent))].

The N+1 trap: looping with `belonging_to(&single)`

It is easy to fall back into TypeORM habits and write a loop:

1
// Anti-pattern: one query per author (N+1).
2
let mut tree = Vec::new();
3
for author in authors {
4
    let posts = Post::belonging_to(&author) // ← runs a SELECT every iteration
5
        .select(Post::as_select())
6
        .load(conn)?;
7
    tree.push((author, posts));
8
}

This compiles and works, but issues one query per author. Fix: pass the whole slice once — Post::belonging_to(&authors) — and call grouped_by, as shown above. The slice form generates a single WHERE author_id IN (...).

`grouped_by` order matters

grouped_by(&parents) assumes the same ordering and membership relationship as the parent slice you pass it. Always grouped_by against the exact parent Vec you then zip with, and group bottom-up (deepest children first) when nesting more than one level. Grouping against a different or re-sorted slice silently misaligns buckets.

Counting with a left join: `count_star` over-counts

A natural “posts per author” query using count_star() over a left_join counts the synthetic null row for authors with zero posts, reporting 1 instead of 0. Count a nullable child column instead:

1
use diesel::dsl::count;
2

3
let rows: Vec<(String, i64)> = authors::table
4
    .left_join(posts::table)
5
    .group_by(authors::id)
6
    .select((authors::name, count(posts::id.nullable())))
7
    .load(conn)?;

Verified output (note Lonely, who has no posts):

1
Ada: 2
2
Grace: 1
3
Lonely: 0

count(posts::id.nullable()) ignores nulls, so authors with no posts correctly report 0.

Best Practices

Generate schema.rs from the database with diesel print-schema (driven by real foreign-key constraints) so joinable! and allow_tables_to_appear_in_same_query! are written and kept correct for you. See migrations.md for how migrations establish those constraints.
Default to the belonging_to(&slice) + grouped_by pattern for one-to-many eager loads. Reach for explicit inner_join/left_join when you want flat tuples or you need to filter/sort across both tables in SQL.
Use Selectable + as_select() rather than relying on column order in Queryable. It ties the struct to named columns and, with #[diesel(check_for_backend(...))], makes Diesel verify field types against the backend at compile time.
Select the right side of a left_join as Option<T>. Let the type system represent “may be absent” — do not flatten it away.
Name foreign keys conventionally (author_id, post_id) so the inferred belongs_to foreign key just works; otherwise pass foreign_key = ... explicitly.
Group bottom-up for multi-level trees, and keep the parent Vec around until after the final zip.

Real-World Example

A small “blog dashboard” function that loads every author with their posts and each post’s comments in a fixed three queries, then renders a summary — the kind of payload an API endpoint would serialize. This is the complete, compile-verified program (run against bundled SQLite).

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

4
mod schema {
5
    diesel::table! { authors (id) { id -> Integer, name -> Text, } }
6
    diesel::table! { posts (id) { id -> Integer, author_id -> Integer, title -> Text, } }
7
    diesel::table! { comments (id) { id -> Integer, post_id -> Integer, body -> Text, } }
8
    diesel::joinable!(posts -> authors (author_id));
9
    diesel::joinable!(comments -> posts (post_id));
10
    diesel::allow_tables_to_appear_in_same_query!(authors, posts, comments);
11
}
12
use schema::{authors, comments, posts};
13

14
#[derive(Queryable, Selectable, Identifiable, Debug)]
15
#[diesel(table_name = authors)]
16
#[diesel(check_for_backend(diesel::sqlite::Sqlite))]
17
struct Author { id: i32, name: String }
18

19
#[derive(Queryable, Selectable, Identifiable, Associations, Debug)]
20
#[diesel(belongs_to(Author))]
21
#[diesel(table_name = posts)]
22
#[diesel(check_for_backend(diesel::sqlite::Sqlite))]
23
struct Post { id: i32, author_id: i32, title: String }
24

25
#[derive(Queryable, Selectable, Identifiable, Associations, Debug)]
26
#[diesel(belongs_to(Post))]
27
#[diesel(table_name = comments)]
28
#[diesel(check_for_backend(diesel::sqlite::Sqlite))]
29
struct Comment { id: i32, post_id: i32, body: String }
30

31
/// Load the full author -> posts -> comments tree in three queries.
32
fn load_dashboard(
33
    conn: &mut SqliteConnection,
34
) -> QueryResult<Vec<(Author, Vec<(Post, Vec<Comment>)>)>> {
35
    let authors = authors::table.select(Author::as_select()).load(conn)?;
36
    let posts = Post::belonging_to(&authors).select(Post::as_select()).load(conn)?;
37
    let comments = Comment::belonging_to(&posts).select(Comment::as_select()).load(conn)?;
38

39
    let comments_per_post = comments.grouped_by(&posts);
40
    let posts_with_comments: Vec<(Post, Vec<Comment>)> =
41
        posts.into_iter().zip(comments_per_post).collect();
42
    let grouped = posts_with_comments.grouped_by(&authors);
43
    Ok(authors.into_iter().zip(grouped).collect())
44
}
45

46
fn seed(conn: &mut SqliteConnection) {
47
    for sql in [
48
        "CREATE TABLE authors (id INTEGER PRIMARY KEY, name TEXT NOT NULL)",
49
        "CREATE TABLE posts (id INTEGER PRIMARY KEY, author_id INTEGER NOT NULL, title TEXT NOT NULL)",
50
        "CREATE TABLE comments (id INTEGER PRIMARY KEY, post_id INTEGER NOT NULL, body TEXT NOT NULL)",
51
        "INSERT INTO authors VALUES (1,'Ada'),(2,'Grace')",
52
        "INSERT INTO posts VALUES (1,1,'Rust ownership'),(2,1,'Lifetimes'),(3,2,'Borrow checker')",
53
        "INSERT INTO comments VALUES (1,1,'Great!'),(2,1,'Helpful'),(3,3,'Thanks')",
54
    ] {
55
        diesel::sql_query(sql).execute(conn).unwrap();
56
    }
57
}
58

59
fn main() -> QueryResult<()> {
60
    let mut conn = SqliteConnection::establish(":memory:").unwrap();
61
    seed(&mut conn);
62

63
    for (author, posts) in load_dashboard(&mut conn)? {
64
        println!("{}:", author.name);
65
        for (post, comments) in posts {
66
            println!("    {} ({} comments)", post.title, comments.len());
67
        }
68
    }
69
    Ok(())
70
}

Real output:

1
Ada:
2
    Rust ownership (2 comments)
3
    Lifetimes (0 comments)
4
Grace:
5
    Borrow checker (1 comments)

In a real service you would obtain conn from a pool rather than a one-off :memory: connection — see connection-pooling.md — and you would derive serde::Serialize on the structs to return the tree as JSON from a web handler (covered in 15-serialization and 16-web-apis).

Exercises

Exercise 1: Posts for a single author

Difficulty: Easy

Objective: Use belonging_to to load all posts for one author.

Instructions: Given the Author and Post models from this page, write a function fn posts_of(conn: &mut SqliteConnection, author: &Author) -> QueryResult<Vec<Post>> that returns every post belonging to the given author, ordered by title.

Solution

1
use diesel::prelude::*;
2
use diesel::sqlite::SqliteConnection;
3
use crate::schema::posts;
4

5
fn posts_of(conn: &mut SqliteConnection, author: &Author) -> QueryResult<Vec<Post>> {
6
    Post::belonging_to(author)
7
        .order(posts::title.asc())
8
        .select(Post::as_select())
9
        .load(conn)
10
}

belonging_to(author) builds WHERE posts.author_id = <author.id>; it returns an ordinary query, so you can chain .order(...), .filter(...), etc. before .load. This is verified to compile against Diesel 2.3 with the models from this page.

Exercise 2: Eager-load authors with their posts (no N+1)

Difficulty: Medium

Objective: Load every author paired with their posts in exactly two queries.

Instructions: Write fn authors_with_posts(conn: &mut SqliteConnection) -> QueryResult<Vec<(Author, Vec<Post>)>>. Load all authors, then all their posts in one batched query, group with grouped_by, and zip. Do not issue one query per author.

Solution

1
use diesel::prelude::*;
2
use diesel::sqlite::SqliteConnection;
3
use crate::schema::authors;
4

5
fn authors_with_posts(
6
    conn: &mut SqliteConnection,
7
) -> QueryResult<Vec<(Author, Vec<Post>)>> {
8
    let all_authors = authors::table
9
        .select(Author::as_select())
10
        .load(conn)?; // query 1
11

12
    let posts_per_author = Post::belonging_to(&all_authors)
13
        .select(Post::as_select())
14
        .load(conn)? // query 2: WHERE author_id IN (...)
15
        .grouped_by(&all_authors);
16

17
    Ok(all_authors.into_iter().zip(posts_per_author).collect())
18
}

The slice form of belonging_to plus grouped_by is the canonical Diesel eager-load pattern: two queries regardless of how many authors there are. Verified output for the sample data is Ada has 2 post(s) / Grace has 1 post(s).

Exercise 3: Authors with no posts, via a left join

Difficulty: Hard

Objective: Find every author who has written zero posts, using an outer join.

Instructions: Write fn authors_without_posts(conn: &mut SqliteConnection) -> QueryResult<Vec<Author>>. Use left_join so authors with no posts still appear, select the post side as Option<Post>, and keep only the authors whose post side is None. (Bonus: how would you instead do this purely in SQL with filter + is_null?)

Solution

1
use diesel::prelude::*;
2
use diesel::sqlite::SqliteConnection;
3
use crate::schema::{authors, posts};
4

5
fn authors_without_posts(conn: &mut SqliteConnection) -> QueryResult<Vec<Author>> {
6
    let rows: Vec<(Author, Option<Post>)> = authors::table
7
        .left_join(posts::table)
8
        .select((Author::as_select(), Option::<Post>::as_select()))
9
        .load(conn)?;
10

11
    Ok(rows
12
        .into_iter()
13
        .filter(|(_, post)| post.is_none())
14
        .map(|(author, _)| author)
15
        .collect())
16
}
17

18
// Bonus: push the filter into SQL so the database does the work.
19
fn authors_without_posts_sql(conn: &mut SqliteConnection) -> QueryResult<Vec<Author>> {
20
    authors::table
21
        .left_join(posts::table)
22
        .filter(posts::id.is_null())
23
        .select(Author::as_select())
24
        .load(conn)
25
}

The first version loads (Author, Option<Post>) tuples and filters in Rust; an author with no posts yields exactly one (author, None) row. The bonus version pushes WHERE posts.id IS NULL into SQL, which is more efficient because the database filters before returning rows. Both compile against Diesel 2.3.

Diesel Relations: Associations, Joins, and Eager Loading

Quick Overview

TypeScript/JavaScript Example

Rust Equivalent

Detailed Explanation

Declaring the relationship

belonging_to for a single parent

belonging_to for many parents + grouped_by (the eager-load pattern)

SQL joins for flat rows

Three-level eager loading

Key Differences

Common Pitfalls

Forgetting joinable! / allow_tables_to_appear_in_same_query!

Forgetting Identifiable (or Associations) for belonging_to

The N+1 trap: looping with belonging_to(&single)

grouped_by order matters

Counting with a left join: count_star over-counts

Best Practices

Real-World Example

Further Reading

Exercises

Exercise 1: Posts for a single author

Exercise 2: Eager-load authors with their posts (no N+1)

Exercise 3: Authors with no posts, via a left join

`belonging_to` for a single parent

`belonging_to` for many parents + `grouped_by` (the eager-load pattern)

Forgetting `joinable!` / `allow_tables_to_appear_in_same_query!`

Forgetting `Identifiable` (or `Associations`) for `belonging_to`

The N+1 trap: looping with `belonging_to(&single)`

`grouped_by` order matters

Counting with a left join: `count_star` over-counts