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