Mina Choi
3910feddfb
0005 가 도메인 스키마를 걷어내고 표 이름을 옮겼는데 `init.sql` 은 94줄이 **추가**만 됐고 삭제가 0줄이었다. 그래서 이 파일 한 벌로 세운 DB 는 `place.place_links`·`job.jobs` 를 갖고 ORM 은 `public.place_channels`·`public.jobs` 를 찾는다 — 기동은 정상이고 첫 쿼리에서 죽는다. "init.sql 은 새 DB 를 세우는 전체 DDL 이고 계속 최신을 유지한다"(migrations/README.md)는 계약이 깨져 있었다. 이걸 잡아야 할 test_schema_ddl.py 는 로컬 DB 인증 실패로 5건 전부 error 라 안 돌고 있어서 안 걸렸다. - init.sql: public 한 벌 · 표 14개로 다시 썼다. 옛 도메인 스키마가 있는 DB 에서 다시 돌면 RAISE EXCEPTION 으로 멈춘다 — 그대로 두면 public 에 빈 표가 생기고 0005 가 "relation already exists" 로 실패해 데이터가 옛 스키마에 갇힌다 - init.sql 말미에 **마이그레이션 기준선**을 심는다. 이게 없으면 새 DB 에서 migrate.py 가 0001 부터 다시 돌다가 `schema "local" does not exist` 로 죽는다 - 0009: 두 DB 를 실제로 찍어 비교해 나온 어긋남 셋 · `idx_site_contents_site` 가 기존 DB 에만 없었다(0003 이 유니크만 걸었다) — 섹션 조회가 시퀀셜 스캔 · `places.external_place_id` VARCHAR(32) → (64). ORM 은 64 다 — 긴 id 가 잘리면 동일 업소 판정이 조용히 틀린다 · 0005 의 RENAME 이 안 따라간 PK 제약 이름 9개(`facts_pkey` → `place_facts_pkey` …) - models.py: `area_contents.region_code` 를 nullable 로. 0004 가 DROP NOT NULL 한 것을 ORM 만 NOT NULL 로 들고 있었다 — 축제·관광지·맛집은 전국 공용이라 지역이 유일성의 근거가 아니다 검증: 빈 컨테이너에 init.sql 로 세운 DB 와 마이그레이션으로 따라온 로컬 DB 를 `pg_dump --schema-only` 로 비교 — 표 14개 · 인덱스 · 제약 · 컬럼 전부 동일. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
44 lines
3.6 KiB
SQL
44 lines
3.6 KiB
SQL
-- 0009 · init.sql 을 현재 스키마로 다시 쓰면서 드러난 어긋남을 맞춘다
|
|
--
|
|
-- ★ 어떻게 찾았나 (2026-09-10)
|
|
-- `init.sql` 이 0005 의 스키마 해체를 따라오지 않아 옛 도메인 스키마를 그대로 만들고 있었다.
|
|
-- 그걸 현재 모습으로 다시 쓴 뒤, **빈 컨테이너에 새로 세운 DB** 와 **마이그레이션으로 따라온
|
|
-- 기존 DB** 를 `pg_dump --schema-only` 로 나란히 놓고 비교했다. 표 목록은 같았고 아래 셋이 달랐다.
|
|
-- 이 비교는 앞으로도 같은 방법으로 한다 — ORM 주석이나 기억이 아니라 두 DB 를 실제로 찍어 본다.
|
|
--
|
|
-- ★ 이 파일은 데이터를 건드리지 않는다. 이름·타입·인덱스만 맞춘다.
|
|
|
|
-- ── 1. 없는 인덱스 (실사용에 영향) ──────────────────────────────────────
|
|
-- 0003 이 기존 DB 에 site_contents 를 만들 때 유니크(uq_site_contents_section)만 걸고
|
|
-- place 조회용 인덱스를 빠뜨렸다. init.sql 에는 처음부터 있었으므로 **새 DB 에만 있고
|
|
-- 기존 DB 에는 없는** 상태였다 — 사이트 하나의 섹션을 읽을 때마다 시퀀셜 스캔이다.
|
|
CREATE INDEX IF NOT EXISTS idx_site_contents_site ON public.site_sections (site_id);
|
|
|
|
-- ── 2. 컬럼 폭 (ORM 과 불일치) ──────────────────────────────────────────
|
|
-- ORM 은 String(64) 인데 DB 는 VARCHAR(32) 였다. 지금 쓰는 카카오 place id 는 8~10자라
|
|
-- 아직 안 터졌지만, 다른 출처(네이버·TourAPI)의 id 를 넣는 날 잘려 들어간다 —
|
|
-- 잘린 id 는 "동일 업소 판정" 을 조용히 틀리게 만드는 종류다.
|
|
ALTER TABLE public.places ALTER COLUMN external_place_id TYPE VARCHAR(64);
|
|
|
|
-- ── 3. 옛 이름이 남은 PK 제약 ───────────────────────────────────────────
|
|
-- `ALTER TABLE ... RENAME TO` 는 제약 이름을 따라 바꾸지 않는다. 그래서 0005 이후로
|
|
-- `place_facts` 의 PK 가 `facts_pkey` 로 남아 있었다. 동작에는 영향이 없지만,
|
|
-- 스키마를 덤프해 비교할 때마다 "새 DB 와 기존 DB 가 다르다" 로 보인다 —
|
|
-- 진짜 차이를 찾는 눈을 가리는 잡음이라 지금 맞춰 둔다.
|
|
ALTER INDEX IF EXISTS public.facts_pkey RENAME TO place_facts_pkey;
|
|
ALTER INDEX IF EXISTS public.faqs_pkey RENAME TO place_faqs_pkey;
|
|
ALTER INDEX IF EXISTS public.media_pkey RENAME TO place_photos_pkey;
|
|
ALTER INDEX IF EXISTS public.units_pkey RENAME TO place_units_pkey;
|
|
ALTER INDEX IF EXISTS public.place_links_pkey RENAME TO place_channels_pkey;
|
|
ALTER INDEX IF EXISTS public.local_contents_pkey RENAME TO area_contents_pkey;
|
|
ALTER INDEX IF EXISTS public.place_contents_pkey RENAME TO place_area_refs_pkey;
|
|
ALTER INDEX IF EXISTS public.site_contents_pkey RENAME TO site_sections_pkey;
|
|
ALTER INDEX IF EXISTS public.publish_logs_pkey RENAME TO site_publish_logs_pkey;
|
|
-- 0004 가 place_contents 를 새로 만들면서 붙은 번호(_pkey1). 위 이름이 이미 비어 있으면
|
|
-- 이쪽이 진짜 PK 다.
|
|
ALTER INDEX IF EXISTS public.place_contents_pkey1 RENAME TO place_area_refs_pkey;
|
|
|
|
-- ★ 인덱스 이름은 바꾸지 않는다(idx_facts_place · uq_place_links_place_url …).
|
|
-- ORM 의 __table_args__ 가 그 이름을 들고 있어서, 여기서 바꾸면 ORM 도 같이 고쳐야 하고
|
|
-- 그 사이에 같은 인덱스가 두 벌 생긴다. 제약 이름과 달리 이건 코드가 참조한다.
|