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>
2.7 KiB
2.7 KiB
kind, slug, title, topic, project, status, sourceRevision, rootTreeNode, verifiedOn
| kind | slug | title | topic | project | status | sourceRevision | rootTreeNode | verifiedOn |
|---|---|---|---|---|---|---|---|---|
| REFERENCE | each-stream-owns-its-history-table | 마이그레이션 스트림은 자기 history 테이블을 갖는다 | schema-ownership-and-capability-streams | clean-architecture-backend-template | 게시 전 | 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 | reference:each-stream-owns-its-history-table |
마이그레이션 스트림은 자기 history 테이블을 갖는다
목적
독립적으로 번호를 매기는 마이그레이션 트리들이 하나의 버전 공간을 공유해, 같은 번호가 충돌하거나 조용히 건너뛰어지는 것을 막는다.
규칙
-
스트림마다 위치와 히스토리 테이블을 함께 준다 위치만 나누고 히스토리를 공유하면 버전 공간은 여전히 하나다.
-
각 스트림은 자기 V1 부터 시작한다 다른 트리의 번호를 신경 쓰지 않아도 된다는 것이 이 구조의 목적이다.
-
위치 목록을 병합하는 구성이 있으면 그 목록이 하나의 버전 공간이다 병합되는 트리들끼리는 번호를 겹치지 않게 골라야 하고, 그 사실을 마이그레이션 헤더에 적는다.
-
중복 버전은 기동 거부다 Flyway 가 병합해 주지 않는다. 배포 시점에 처음 발견된다.
-
여러 위치가 같은 테이블을 만들면 변경도 모든 위치에 적용한다 한쪽으로만 마이그레이션한 배포가 옛 제약을 유지하고, 그때 오류는 이유가 아니라 컬럼 이름을 부른다.
적용 조건
능력별로 나뉜 마이그레이션 트리
리프마다 자기 마이그레이션을 갖는 모듈 구조
예외
한 팀이 하나의 트리만 관리하고 병합될 다른 트리가 없다면 단일 히스토리로 충분하다.
예시
알림 스키마가 자기 위치와 자기 히스토리 테이블을 갖는다. 그래서 알림을 켜지 않은 배포에는 알림 히스토리 테이블도 없다.
메시징 인박스와 아웃박스 리프가 같은 디렉터리 이름을 쓰고 둘 다 V2 를 만든다.
샘플 컴포지션이 두 위치를 병합하므로 번호를 고를 때 다른 트리를 봐야 한다는 사실이 마이그레이션 헤더에 적혀 있다.
관계
- 독립 Flyway 스트림과 baseline version 0 이 규칙이 나온 개념이다.
- 두 트리가 다 V1부터 번호를 매겨 공유 history가 하나를 건너뛸 수 있었다 이 규칙이 없을 때의 결과다.
- messaging 마이그레이션 두 leaf가 같은 디렉터리에서 V2를 둘 만들었다 같은 형태가 다른 가족에서 남아 있는 사례다.