[P1] [DB] 공개용/작업용 seat_positions 스키마 불일치 정리 #12

New Issue

2026-03-27T18:07:57+09:00

hyunho commented

2026-03-27 18:07:57 +09:00

문제

공개용 DB와 작업용 DB의 seat_positions 스키마가 서로 다릅니다.

현재 확인된 차이:

공개용 seat_positions
- member_id
- x
- y
- floor_label
- updated_at
- seat_map_id
- row_index
- col_index
- seat_label
- seat_slot_id
작업용 현재 seat_positions
- member_id
- seat_map_id
- seat_slot_id
- row_index
- col_index
- seat_label
- updated_at

영향

공개용 DB 덤프를 작업용 DB에 그대로 복원할 때 seat_positions 단계에서 실패함
기존 동기화 스크립트가 중간에 멈추거나, 일부 테이블만 복원된 상태로 끝날 수 있음
자리배치도 검증 시 코드 문제와 DB 구조 문제를 분리하기 어려워짐

해야 할 일

공개용/작업용 seat_positions 스키마 기준을 통일
또는 호환 가능한 migration / 변환 레이어 추가
seatmap 조회/저장 로직이 어느 스키마를 기준으로 삼는지 명확히 정리
이후 DB 동기화 절차가 seat_positions 에서 실패하지 않도록 보장

완료 조건

공개용 DB 덤프를 작업용 DB에 그대로 복원해도 seat_positions 단계에서 실패하지 않을 것
자리배치도 API가 기대하는 컬럼 구조가 문서/코드 기준으로 일치할 것

## 문제 공개용 DB와 작업용 DB의 `seat_positions` 스키마가 서로 다릅니다. 현재 확인된 차이: - 공개용 `seat_positions` - `member_id` - `x` - `y` - `floor_label` - `updated_at` - `seat_map_id` - `row_index` - `col_index` - `seat_label` - `seat_slot_id` - 작업용 현재 `seat_positions` - `member_id` - `seat_map_id` - `seat_slot_id` - `row_index` - `col_index` - `seat_label` - `updated_at` ## 영향 - 공개용 DB 덤프를 작업용 DB에 그대로 복원할 때 `seat_positions` 단계에서 실패함 - 기존 동기화 스크립트가 중간에 멈추거나, 일부 테이블만 복원된 상태로 끝날 수 있음 - 자리배치도 검증 시 코드 문제와 DB 구조 문제를 분리하기 어려워짐 ## 해야 할 일 - 공개용/작업용 `seat_positions` 스키마 기준을 통일 - 또는 호환 가능한 migration / 변환 레이어 추가 - seatmap 조회/저장 로직이 어느 스키마를 기준으로 삼는지 명확히 정리 - 이후 DB 동기화 절차가 `seat_positions` 에서 실패하지 않도록 보장 ## 완료 조건 - 공개용 DB 덤프를 작업용 DB에 그대로 복원해도 `seat_positions` 단계에서 실패하지 않을 것 - 자리배치도 API가 기대하는 컬럼 구조가 문서/코드 기준으로 일치할 것

hyunho commented

2026-03-30 09:15:02 +09:00

2026-03-30 정리

이번 작업에서 seat_positions 스키마 불일치 대응을 코드/운영 절차 기준으로 정리했습니다.

반영 내용:

backend/app/db.py
- 구형 seat_positions 스키마에 남아 있을 수 있는 x, y, floor_label 기준 데이터를 현재 컬럼 구조로 흡수하는 migration 경로 유지
- 현재 기준 컬럼/인덱스/slot 제약을 다시 명확히 고정
scripts/sync_prod_db_to_dev.sh
- seat_positions 는 portable CSV 경로로 별도 export/import 하도록 유지
- 따라서 공개용 덤프를 작업용에 그대로 넣을 때 seat_positions 단계에서 스키마 차이로 실패하지 않도록 보강
실제 검증
- ./scripts/sync_prod_db_to_dev.sh minimal 실행 완료
- 결과 수치
  - members=227
  - seat_maps=21
  - seat_slots=57308
  - seat_positions=0
  - seat_label_mismatch=0

현재 판단:

이 이슈의 핵심이었던 seat_positions 스키마 차이로 인한 sync 실패 문제는 정리된 상태로 본다.
이후 추가 스키마 변경이 생기면 별도 migration 범위로 관리하면 된다.

2026-03-30 정리 이번 작업에서 `seat_positions` 스키마 불일치 대응을 코드/운영 절차 기준으로 정리했습니다. 반영 내용: - `backend/app/db.py` - 구형 `seat_positions` 스키마에 남아 있을 수 있는 `x`, `y`, `floor_label` 기준 데이터를 현재 컬럼 구조로 흡수하는 migration 경로 유지 - 현재 기준 컬럼/인덱스/slot 제약을 다시 명확히 고정 - `scripts/sync_prod_db_to_dev.sh` - `seat_positions` 는 portable CSV 경로로 별도 export/import 하도록 유지 - 따라서 공개용 덤프를 작업용에 그대로 넣을 때 `seat_positions` 단계에서 스키마 차이로 실패하지 않도록 보강 - 실제 검증 - `./scripts/sync_prod_db_to_dev.sh minimal` 실행 완료 - 결과 수치 - `members=227` - `seat_maps=21` - `seat_slots=57308` - `seat_positions=0` - `seat_label_mismatch=0` 현재 판단: - 이 이슈의 핵심이었던 `seat_positions` 스키마 차이로 인한 sync 실패 문제는 정리된 상태로 본다. - 이후 추가 스키마 변경이 생기면 별도 migration 범위로 관리하면 된다.

hyunho closed this issue

2026-03-30 09:15:02 +09:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: hyunho/MH-DashBoard-organization#12