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>
61 lines
2.7 KiB
Markdown
61 lines
2.7 KiB
Markdown
---
|
|
kind: REFERENCE
|
|
slug: an-applied-checksum-is-a-promise
|
|
title: 적용된 마이그레이션의 checksum은 그것을 돌린 모든 배포에 대한 약속이다
|
|
topic: schema-ownership-and-capability-streams
|
|
project: clean-architecture-backend-template
|
|
status: 게시 전
|
|
sourceRevision: 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916
|
|
rootTreeNode: reference:an-applied-checksum-is-a-promise
|
|
verifiedOn: # 이 기록은 이번 회차에 실행 확인을 하지 않았다
|
|
---
|
|
|
|
# 적용된 마이그레이션의 checksum은 그것을 돌린 모든 배포에 대한 약속이다
|
|
|
|
## 목적
|
|
|
|
이미 적용된 마이그레이션 파일을 수정해, 그것을 적용한 배포와 앞으로 적용할 배포가 서로 다른 스키마를 갖게 되는 것을 막는다.
|
|
|
|
## 규칙
|
|
|
|
1. 적용된 파일은 수정하지 않는다
|
|
체크섬이 바뀌면 그 파일을 이미 적용한 배포에서 검증이 실패한다.
|
|
|
|
2. 고쳐야 할 것은 새 마이그레이션으로 고친다
|
|
앞의 것을 되돌리거나 보정하는 마이그레이션을 새로 만든다.
|
|
|
|
3. 새 마이그레이션은 순서에 무관하게 동작하도록 가드한다
|
|
여러 스트림이 같은 대상을 만들 수 있으면, 어느 쪽이 먼저 돌든 올바르게 끝나야 한다.
|
|
|
|
4. 반복 비용을 두 번 내지 않는다
|
|
이미 처리된 대상은 건너뛴다. 테이블 재작성 같은 비싼 작업일수록 중요하다.
|
|
|
|
5. 수정 이력을 헤더에 남긴다
|
|
왜 새 번호가 필요했는지가 그 파일에 있어야 다음 사람이 앞의 것을 고치려 하지 않는다.
|
|
|
|
## 적용 조건
|
|
|
|
버전 기반 마이그레이션을 쓰는 모든 스키마 관리
|
|
|
|
여러 배포가 서로 다른 시점에 마이그레이션을 적용하는 환경
|
|
|
|
## 예외
|
|
|
|
아직 어떤 환경에도 적용되지 않은 마이그레이션은 수정할 수 있다. 그 판단에는 모든 환경을 확인했다는 근거가 필요하다.
|
|
|
|
## 예시
|
|
|
|
컬럼 타입을 바꾸는 마이그레이션이 앞의 마이그레이션을 고치는 대신 새 번호로 추가되었고, 두 스트림의 순서가 고정되어 있지 않아 아직 옛 타입인 컬럼만 변환하도록 가드했다.
|
|
|
|
컬럼을 넓히는 마이그레이션이 두 위치 모두에 필요했다. 한쪽만 적용한 배포는 옛 제약을 유지한다.
|
|
|
|
## 관계
|
|
|
|
- **char(64)와 varchar(64) 불일치를 H2가 가리고 있었다**
|
|
이 규칙을 따른 수정의 사례다.
|
|
- **레지스트리 컬럼이 38자 경로에서 짧아 더 짧은 경로를 적는 우회를 유혹했다**
|
|
다섯 번째 규칙의 사례다.
|
|
- **Repair는 모드가 아니라 운영자가 호출하는 작업이다**
|
|
체크섬 불일치를 다루는 결정이다.
|
|
|