migration repair 를 하기 전에 무엇이 다른지 먼저 확인했다. 이력에는 10개 중 3개만 기록돼 있고 나머지는 SQL 편집기로 직접 만든 상태라, 그대로 repair 하면 파일과 DB 가 다른데 같다고 기록돼 db diff·db pull 이 어긋난 결과를 낸다. 정본은 마이그레이션 파일로 정했다(haewon 2026-09-14). 결과: 표 17개 중 15개가 정확히 일치한다. 손볼 곳은 세 가지다. - clinic_registry: 파일에만 is_active·verified_at·verified_by, DB 에만 notes. notes 는 74곳 전부에 값이 있어 실제로 쓰이므로 파일에 반영해야 한다. - channel_latest·channel_weekly_delta 는 뷰이고 정의가 마이그레이션 파일에 없다. DB 는 조회만 했고 바꾸지 않았다. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
62 lines
3.6 KiB
Markdown
62 lines
3.6 KiB
Markdown
# 마이그레이션 파일과 운영 DB 대조표
|
|
|
|
작성 2026-09-14 · 읽기 전용 조회 결과입니다. 이 문서를 만들며 DB 를 바꾸지 않았습니다.
|
|
|
|
**정본은 마이그레이션 파일입니다**(haewon 결정 2026-09-14).
|
|
|
|
## 왜 필요한가
|
|
|
|
`supabase migration list` 기준으로 로컬 마이그레이션 10개 중 **원격 이력에 기록된 것은 3개**뿐입니다.
|
|
나머지는 SQL 편집기로 직접 만들어 이력에 남지 않았습니다.
|
|
이 상태에서 `migration repair` 로 "적용됨"을 기록하면 파일과 DB 가 실제로는 다른데 같다고 기록돼
|
|
`db diff`·`db pull` 이 어긋난 결과를 냅니다. 그래서 repair 전에 무엇이 다른지 먼저 확인했습니다.
|
|
|
|
## 대조 결과
|
|
|
|
| 테이블 | 상태 | 파일에만 있음 (DB 에 추가 필요) | DB 에만 있음 (파일에 반영 필요) | 비고 |
|
|
|---|---|---|---|---|
|
|
| `analysis_runs` | 일치 | - | - | - |
|
|
| `channel_configs` | 일치 | - | - | - |
|
|
| `channel_latest` | 뷰 | - | captured_at, channel, clinic_id, followers, handle, health_score, health_status, posts, rating, rating_scale, reviews, screenshot_url, total_views | VIEW 입니다. 마이그레이션 파일에 정의가 없습니다 |
|
|
| `channel_snapshots` | 일치 | - | - | - |
|
|
| `channel_weekly_delta` | 뷰 | - | captured_at, channel, clinic_id, current_followers, current_reviews, followers_change_pct, prev_followers, prev_reviews | VIEW 입니다. 마이그레이션 파일에 정의가 없습니다 |
|
|
| `clinic_registry` | 다름 | is_active, verified_at, verified_by | notes | - |
|
|
| `clinics` | 일치 | - | - | - |
|
|
| `content_performance` | 일치 | - | - | - |
|
|
| `content_plans` | 일치 | - | - | - |
|
|
| `discovery_leads` | 일치 | - | - | - |
|
|
| `marketing_reports` | 일치 | - | - | - |
|
|
| `performance_metrics` | 일치 | - | - | - |
|
|
| `scrape_results` | 일치 | - | - | - |
|
|
| `screenshots` | 일치 | - | - | - |
|
|
| `strategy_adjustments` | 일치 | - | - | - |
|
|
| `supporter_builds` | 일치 | - | - | - |
|
|
| `supporter_inputs` | 일치 | - | - | - |
|
|
|
|
표 17개 중 **15개가 정확히 일치**합니다. 손볼 곳은 `clinic_registry` 하나와 정의가 빠진 뷰 2개입니다.
|
|
|
|
## 확인한 것
|
|
|
|
- `channel_latest`·`channel_weekly_delta` 는 **뷰(VIEW)** 입니다. 표가 어긋난 것이 아니라 뷰 정의가 마이그레이션 파일에 없습니다.
|
|
- `clinic_registry` 의 `notes` 는 **74곳 전부에 값이 있어 실제로 쓰이는 컬럼**입니다. 지우면 안 되고 파일에 반영해야 합니다.
|
|
- `is_active`·`verified_at`·`verified_by` 는 파일에만 있습니다. 코드가 쓰는지 확인한 뒤 추가할지 파일에서 뺄지 정합니다.
|
|
|
|
## 다음에 할 일 (순서를 바꾸면 안 됩니다)
|
|
|
|
1. `clinic_registry` 의 `is_active`·`verified_at`·`verified_by` 를 운영 DB 에 추가하거나, 쓰지 않으면 마이그레이션 파일에서 뺍니다.
|
|
2. `notes` 컬럼과 뷰 2개의 정의를 마이그레이션 파일에 추가합니다.
|
|
3. 둘이 맞은 뒤에 `supabase migration repair --status applied <version>` 으로 이력을 맞춥니다.
|
|
4. 그다음부터 `supabase db push` 가 새 마이그레이션만 적용합니다.
|
|
|
|
3번을 먼저 하면 어긋난 상태가 기록으로 굳습니다.
|
|
|
|
## 대조 방법
|
|
|
|
```
|
|
supabase db query --linked -o csv \
|
|
"select table_name, column_name from information_schema.columns where table_schema='public' order by table_name, ordinal_position;"
|
|
```
|
|
|
|
파일 쪽은 `CREATE TABLE` 과 `ALTER TABLE ... ADD COLUMN` 을 파싱해 모았습니다.
|
|
제약·인덱스·함수·트리거·RLS 는 이 대조에 넣지 않았습니다. 컬럼만 봅니다.
|