fix(api): batch-fetch comicMetadata to eliminate N+1 #2
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "bd-grimmory-n55.4"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
Bead: grimmory-n55.4 (part of epic grimmory-n55 — Scale to tens of thousands of books)
BookMetadataEntity.comicMetadatawas a LAZY@OneToOnewith no@BatchSize, while every sibling association on the same entity had@BatchSize(20). Iterating any large book list (e.g. the unpaginatedGET /api/v1/books) triggered an N+1 oncomic_metadataeven after the other associations were batched.This change adds
@BatchSize(20)oncomicMetadataso it follows the same pattern as the rest of the entity.What changed
BookMetadataEntity.java: one annotation.BookMetadataComicBatchFetchTest.java: new@DataJpaTestusing HibernateStatisticsthat asserts the SQL statement count when accessingcomicMetadataacross N books isceil(N/20)instead ofN.Baseline (production, 65,758 books)
GET /api/v1/books?withDescription=false&stripForListView=truetools/perf/measure-books-api.sh(PR #2, bd-grimmory-n55.1) after this merges should show measurable improvement.Test plan
just api testandjust api check. Agent had no Java 25 toolchain locally so these were not executed before push.tools/perf/measure-books-api.shagainst the production server after merge and capture the new TTFB on bead grimmory-n55.1.