Mina Choi
e0d45eda97
0005 가 도메인 스키마를 걷어내고 표 이름을 옮겼는데, 문자열로 표 이름을 들고 있던 자리들이
따라오지 않았다. import 도 타입검사도 pyflakes 도 못 잡는 종류라 전부 **실행되는 순간에만**
터졌고, 그동안 pytest 는 569건이 통째로 죽어 있어 아무것도 못 잡고 있었다.
**init.sql 이 새 DB 를 옛 구조로 세우고 있었다**
64ce467 이 이 파일에 94줄을 더하기만 하고 삭제를 0줄 했다. 그래서 이 파일 한 벌로 세운 DB 는
`place.place_links`·`job.jobs` 를 갖고 ORM 은 `public.place_channels`·`public.jobs` 를 찾는다 —
기동은 정상이고 첫 쿼리에서 죽는다. "init.sql 은 새 DB 를 세우는 전체 DDL 이고 계속 최신을
유지한다"(migrations/README.md)는 계약이 깨져 있었다.
- public 한 벌 · 표 14개로 다시 썼다. 옛 스키마가 있는 DB 에서 다시 돌면 RAISE EXCEPTION 으로
멈춘다 — 그대로 두면 public 에 빈 표가 생기고 0005 가 "relation already exists" 로 실패해
데이터가 옛 스키마에 갇힌다
- 말미에 **마이그레이션 기준선**을 심는다. 없으면 새 DB 에서 migrate.py 가 0001 부터 다시 돌다가
`schema "local" does not exist` 로 죽는다
**운영 버그 둘** — 두 DB(새로 세운 것 · 마이그레이션으로 따라온 것)를 pg_dump 로 찍어 비교해 찾았다
- `upsert_weather` 의 ON CONFLICT 술어에 `kind IS NULL` 이 빠져 **날씨 캐시 저장이 계속 실패**하고
있었다(0007 이 인덱스에 그 조건을 더했다). 캐시라 화면이 안 죽고 로그에만 남았다.
포스트그레스는 술어가 인덱스 술어를 함의하는지 보고 아니면 "no unique or exclusion constraint
matching" 으로 거절한다 — 컬럼도 표도 멀쩡해서 눈으로는 원인이 안 보인다
- ORM 의 `area_contents` 인덱스 정의가 0004·0007·0008 을 하나도 안 따라왔다. 테스트 DB 는 이
모델로 세워지므로 **테스트가 운영과 다른 제약 아래에서 돌고 있었다**
**0009** — 두 DB 비교에서 나온 어긋남 셋(데이터는 안 건드린다)
- `idx_site_contents_site` 가 기존 DB 에만 없었다(0003 이 유니크만 걸었다) — 섹션 조회가 시퀀셜 스캔
- `places.external_place_id` VARCHAR(32) → (64). ORM 은 64 다 — 긴 id 가 잘리면 동일 업소 판정이 틀린다
- RENAME 이 안 따라간 PK 제약 이름 9개(`facts_pkey` → `place_facts_pkey` …)
**테스트를 살린다**
- conftest 의 TRUNCATE 가 표 이름을 **손으로 나열**하고 있었다. 0005 가 이름을 옮기자 전 테스트가
`relation "place_aliases" does not exist` 로 죽었다 — 이제 ORM 메타데이터에서 뽑아 다시 어긋날 수 없다
- `test_schema_ddl` 이 모델 표를 `"None.users"` 로 조회해 **한 표도 비교하지 않고 통과**하고 있었다.
init.sql 이 조용히 어긋난 동안 이 테스트는 초록이었다. 비교한 표 수를 세는 단언을 더한다
- 테스트 SQL 15곳의 옛 표 이름, `_run_worker` 1틱 문제(수집 뒤 따라오는 LOCAL_SYNC 를 집어 가
정작 기다리던 잡이 PENDING 으로 남았다), 지역 캐시 픽스처(읽는 코드가 옳게 거르는데 테스트가 빨개졌다)
**문서**
- `docs/DATA_MODEL.md` 신설 — 표 14개가 무엇을 담고 누가 쓰는지, 값 하나가 DB 에서 페이지까지
가는 길, 두 번 도는 게이트, **DB 에 없는 것**
- `SERVERS.md` DB 절을 마이그레이션 체계로. 배포에 `migrate.py` 를 넣는다 — 코드만 갈면 컨테이너는
정상으로 뜨고 가게 등록·수집·발행만 죽는다
- ARCHITECTURE 2절의 프리렌더 컨테이너가 `solution-frontend` 로 적혀 있었다. 굽는 건
`solution-prerender` 고 전자는 운영에서 뜨지도 않는다 — AGENTS.md 가 함정으로 적어 둔 그 혼동을
문서가 만들고 있었다
- 옛 표 이름 잔재(`place_links`·`local_contents`·`job.jobs`·`company.users`·`fact.facts`·`ai_check_results`)
검증: 빈 컨테이너에 init.sql 로 세운 DB ↔ 마이그레이션으로 따라온 DB 를 `pg_dump --schema-only`
로 비교 — 표·인덱스·제약·컬럼 전부 동일. pytest 583건 중 581 통과(남은 2건은 `.env` 누수·
레이트리밋 카운터로 환경 문제다). 구글 로그인 21건 포함.
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 도 같이 고쳐야 하고
|
|
-- 그 사이에 같은 인덱스가 두 벌 생긴다. 제약 이름과 달리 이건 코드가 참조한다.
|