DongHyeonkaandClaude Opus 5
b2963105a8
The keycloak project ended with four open questions that design could not
settle. A two-VM lab was built to answer them by measurement, and this is
that material: 26 experiments, 125 raw command outputs, 22 browser captures.
Follows the import procedure in README.md.
source/ the originating repository verbatim — 78 documents, 28 SVGs,
8 manifests, plus .source-revision recording the commit
final/ the SSOT
document.md 729 lines written from the 29 experiment documents, not
concatenated: what was predicted, what was measured, and
where the measurement itself was wrong
evidence/raw 125 outputs, flattened to <experiment>__<file> because
the originals collided (01-baseline.txt appeared three
times) and the audit only globs the top level
evidence/meta one per raw file; command and exitCode are null and the
README says why rather than inventing them
evidence/browser 22 captures
assets/ three diagrams through techviz
.techviz/ their VizSpecs
A separate project rather than an addition to keycloak: the B-layer answers
that project's four questions, but the A, C and D layers are about cluster
failure, SSO and operations, and one document.md should hold one subject.
The four question records there can point here through 관계.
Recorded rather than papered over: only three of the 28 diagrams were
remade. The repository forbids hand-drawn SVG and forbids titles inside the
canvas; all 28 originals carry both, so converting them is redrawing, not
reformatting. They stay in source/ and the gap is written into the document.
verify-pipeline.py passes. audit-records.py reports no issues.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
52 lines
2.8 KiB
Plaintext
52 lines
2.8 KiB
Plaintext
# 지원 매트릭스가 이 게이트에 붙인 목적
|
|
115:| `collection-fetch-pagination` | gate | a paged collection fetch silently reading the whole table and paginating in memory |
|
|
|
|
# 테스트가 무엇을 단언한다고 적는가
|
|
16:/**
|
|
17: * The collection-fetch pagination gate (design §26).
|
|
18: *
|
|
19: * <p>The failure this exists to catch is in-memory pagination: older providers fetched every
|
|
20: * matching parent row and applied the page in Java, logging a warning and returning correct results
|
|
21: * while reading the whole table. Correct output, unbounded work, and nothing failing anywhere.
|
|
22: *
|
|
23: * <p>The assertion is therefore on the <em>generated SQL</em>, not on the returned page size. The
|
|
24: * page is identical either way; only the SQL says where the limit was applied.
|
|
25: */
|
|
26:@Tag("jpa-contract")
|
|
27:class HibernateCollectionFetchPaginationContractTest {
|
|
28:
|
|
29: private static final int PARENTS = 50;
|
|
30: private static final int CHILDREN_PER_PARENT = 4;
|
|
31: private static final int PAGE_SIZE = 20;
|
|
|
|
# 그 테스트가 실제로 단언하는 것
|
|
3:import static org.assertj.core.api.Assertions.assertThat;
|
|
29: private static final int PARENTS = 50;
|
|
30: private static final int CHILDREN_PER_PARENT = 4;
|
|
31: private static final int PAGE_SIZE = 20;
|
|
63: @DisplayName("a paged collection fetch bounds the parent selection in SQL")
|
|
78: assertThat(page).hasSizeLessThanOrEqualTo(expected.maxReturnedParents());
|
|
79: assertThat(expected.requiresDatabaseLimit()).isTrue();
|
|
83: @DisplayName("the fetched page issues one statement, not one per parent")
|
|
97: page.forEach(parent -> assertThat(parent.children()).isNotNull());
|
|
101: assertThat(delta.preparedStatements())
|
|
107: @DisplayName("without a fetch join the same access is an N+1")
|
|
118: page.forEach(parent -> assertThat(parent.children()).hasSize(CHILDREN_PER_PARENT));
|
|
122: assertThat(delta.collectionFetches())
|
|
128: @DisplayName("row amplification stays inside the declared bound")
|
|
141: assertThat(rows).isLessThanOrEqualTo(expected.maxRowAmplification());
|
|
|
|
# 두 번째 단언이 보는 값은 어디서 오는가
|
|
33: public static FetchPaginationExpectation hibernate74PostgreSql(int pageSize) {
|
|
34: return new FetchPaginationExpectation(pageSize, true, pageSize * 100);
|
|
33: public static FetchPaginationExpectation hibernate74PostgreSql(int pageSize) {
|
|
34- return new FetchPaginationExpectation(pageSize, true, pageSize * 100);
|
|
35- }
|
|
|
|
# 같은 리프의 이웃 클래스가 이 형태를 이름으로 부른다
|
|
16- *
|
|
17- * <p>The alternative — asserting the declared baseline as if it were the runtime one — would give a
|
|
18: * green check that proves the constant equals itself while the collection-fetch-pagination gate
|
|
19- * runs against a different provider entirely. See {@code docs/jpa/repository-adaptation.md} §4.
|
|
20- */
|