From 691b70d599a7fe2f5404d4d633ba1a66ac315821 Mon Sep 17 00:00:00 2001 From: Mina Choi Date: Fri, 11 Sep 2026 14:25:13 +0900 Subject: [PATCH] =?UTF-8?q?[fix]=20postgres-init:=20=ED=9A=8C=EC=82=AC=20?= =?UTF-8?q?=EC=A0=9C=EA=B1=B0=20=EB=A7=88=EC=9D=B4=EA=B7=B8=EB=A0=88?= =?UTF-8?q?=EC=9D=B4=EC=85=98=200000=20=EC=B6=94=EA=B0=80=20=E2=80=94=20?= =?UTF-8?q?=ED=82=B9=EC=84=9C=EB=B2=84=20DB=20=EA=B0=80=200005=20=EC=97=90?= =?UTF-8?q?=EC=84=9C=20=EB=A7=89=ED=9E=88=EB=8D=98=20=EA=B2=83?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 회사(테넌트) 제거(94551af, 09-08)는 migrations 폴더가 생기기 전 변경이라 init.sql 의 DO 블록으로만 있었고, 09-10 init.sql 재작성 때 사라졌다. 로컬 DB 는 이미 따라와 있어 드러나지 않았다. 실측(킹서버 2026-09-11): schema_migrations 가 없는 옛 구조 DB 에서 0005 의 `DROP SCHEMA company RESTRICT` 가 company.companies(3행) 때문에 실패 — 0001~0010 이 하나도 못 들어간다. - 0000_drop_companies.sql: 94551af 의 블록 그대로 — owner_user_id 백필(회사의 가장 먼저 만든 계정) → 주인 없는 업장 삭제 → NOT NULL → places.company_id · users.company_id · companies 삭제. 0005 보다 앞이어야 해서 0000. 이미 전부 적용한 DB 에는 마지막에 돌므로 전부 존재 검사로 감쌌다 - README: 번호 규칙의 예외 한 줄 킹서버 덤프 복원본 리허설: 0000~0010 11건 적용, 업장 32곳 owner_null 0 · 삭제 0, 행 수 보존(사진 255 · 사실 86 · 객실 222 · 사이트 22), 적용된 DB 에 0000 재실행 무해. init.sql 로 세운 DB 와 스키마 비교 차이 1건(idx_local_contents_status) — 다음 커밋 Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01CEQ9auj65yJKk2MnWbtRqU --- .../migrations/0000_drop_companies.sql | 37 +++++++++++++++++++ postgres-init/migrations/README.md | 2 + 2 files changed, 39 insertions(+) create mode 100644 postgres-init/migrations/0000_drop_companies.sql diff --git a/postgres-init/migrations/0000_drop_companies.sql b/postgres-init/migrations/0000_drop_companies.sql new file mode 100644 index 0000000..d993cf8 --- /dev/null +++ b/postgres-init/migrations/0000_drop_companies.sql @@ -0,0 +1,37 @@ +-- 0000 · 회사(테넌트) 제거를 기존 DB 에 적용한다 — owner_user_id 백필 → company_id 삭제 → companies 삭제 +-- +-- ★ 왜 이 파일이 늦게 생겼나 (2026-09-11) +-- 회사 제거(94551af, 2026-09-08)는 이 폴더가 생기기(09-09) **전**의 변경이라 init.sql 안의 +-- DO 블록으로만 있었다. 09-10 init.sql 을 현재 모습으로 다시 쓰면서 그 블록이 사라졌고, +-- 로컬 DB 는 그 사이 init.sql 로 이미 따라와 있어서 아무도 몰랐다. +-- 실측(킹서버): 회사가 살아 있는 채로 남은 DB 는 0005 의 `DROP SCHEMA company RESTRICT` 에서 +-- 멈춘다(company.companies 3행) — 0001~0010 이 하나도 못 들어간다. +-- +-- ★ 왜 0000 인가 — 0005 보다 먼저 돌아야 하고, 시간 순으로도 폴더의 어떤 변경보다 앞이다. +-- 새 파일은 여전히 번호를 이어 붙인다(README). 이 번호는 이 파일 하나의 예외다. +-- +-- ★ 0001~0010 을 이미 적용한 DB 에는 이 파일이 **마지막에** 돈다(기록에 없으므로). +-- 그래서 전부 존재 검사로 감싼다 — 그런 DB 에는 place·company 스키마가 없어 아무것도 안 한다. +-- +-- ★ 규칙은 94551af 그대로다. 주인은 그 회사의 **가장 먼저 만든 계정**이고, 주인을 못 찾은 업장은 +-- 지운다 — 스코프가 없으면 아무에게도 안 보이는 유령이다. +-- 실측(킹서버 2026-09-11): 업장 32곳 모두 회사에 계정이 하나씩 있어 삭제 0건. + +DO $$ +BEGIN + IF EXISTS (SELECT 1 FROM information_schema.columns + WHERE table_schema='place' AND table_name='places' AND column_name='company_id') THEN + UPDATE place.places p + SET owner_user_id = ( + SELECT u.user_id FROM company.users u + WHERE u.company_id = p.company_id AND u.deleted = FALSE + ORDER BY u.created_at LIMIT 1) + WHERE p.owner_user_id IS NULL; + DELETE FROM place.places WHERE owner_user_id IS NULL; + ALTER TABLE place.places ALTER COLUMN owner_user_id SET NOT NULL; + ALTER TABLE place.places DROP COLUMN company_id; + END IF; +END $$; + +ALTER TABLE IF EXISTS company.users DROP COLUMN IF EXISTS company_id; +DROP TABLE IF EXISTS company.companies; diff --git a/postgres-init/migrations/README.md b/postgres-init/migrations/README.md index 56b06e1..a3034a3 100644 --- a/postgres-init/migrations/README.md +++ b/postgres-init/migrations/README.md @@ -17,6 +17,8 @@ TourAPI 가 주변 정보를 받아 와도 저장할 곳이 없어 축제·맛 ## 규칙 - 파일명 `NNNN_한글_요약.sql` — 번호는 이어 붙인다. 지운 번호를 재사용하지 않는다. + ★ 예외는 `0000_drop_companies` 하나다 — 이 폴더가 생기기 전(09-08) 변경을 뒤늦게 옮긴 것이라 + 0005 보다 앞에 둔다. 이미 전부 적용한 DB 에는 마지막에 돌므로 존재 검사로 감싸 두었다(파일 머리주석). - **재실행 안전하게 쓴다**(`IF NOT EXISTS` · `ADD COLUMN IF NOT EXISTS`). 적용 기록이 있어도 사람이 손으로 한 번 더 돌릴 수 있다. - 한 파일 = 한 가지 변경. 여러 테이블을 건드려도 목적이 하나면 한 파일이다.