PostgreSQL
FK 제약 에러
발단
- 사전의 계획은 다음과 같음
- 테이블의 필드값을 복사하고(
tmp_linkhub_link
) 링크의 포지션값을 업데이트한 후에 이름을 서로 바꾸어 서비스를 원상복구 하는 것!
기존 시나리오
- 기존 시나리오의 플로우
tmp_linkhub_link
생성(후: linkhub_link
)
- 새롭게 대체할 데이터 베이스
- django 서버가 추후에 바라보게 될 테이블
- 기존
linkhub_link
변경 (후: dummy_linkhub_link
)
- 기존의 테이블이자 대체될 테이블
- django 서버가 기존에 바라보고 있는 테이블
- fake 마이그레이션
- 마이그레이션을 한다는 것은 넓은 의미로
- DB의 정보를 수정하거나
- 데이터를 집어넣어서 DB를 세팅하는 것을 말함
- django를 이용하여 model과 테이블을 1:1 대응이 되도록 매핑하는 의미로 봐도 무방
→ python manage.py migrate <app_name> --fake
를 이용해서 수동으로 세팅한 DB가 django로 마이그레이션을 한 것과 같은 효과를 줄 예정
문제 발생/원인
- 테이블을 생성하고 django 서버가 바라보는 테이블을 변경했음에도 아래와 같은
foreign key constraint
가 발생
- 에러메시지를 읽어보면 DB 테이블에서 외래키로 바라보는 테이블이 기존에 바라보던 테이블을 계속 바라보고 있어 생기는 문제
- 위의 문제는
ALTER TABLE
이라는 DDL을 가지고 테이블 이름만을 변경하였기 때문에 발생하는 문제
- 외래키의 경우 테이블의 이름이 아닌 테이블 고유 식별자를 통해 연결되어있기 때문에 테이블의
foreign key constraint
를 추적해야 함
해결
- 아래와 같이
foreign key
까지 제대로 수정해야함
- 먼저 테이블의 세부 정보를 통해서 왜래키 제약 정보를 확인하여 우리의 예측이 맞는지 확인
\d <table name>
을 통해서 세부 정보를 확인할 수 있음
- 다음으로 잘못된 외래키 제약을 삭제
ALTER TABLE <table name> DROP CONSTRAINT <foreign key constraint id>
- 새로운 외래키를 추가
ALTER TABLE <table name> ADD CONSTRAINT <contraint id> FOREIGN KEY (<field>) REFERENCES <target_table>(id)
- 위의 결과를 실행하고 나면
test
라는 이름의 제약이 생긴 것을 확인할 수 있음
→ 이외에도 CASCADE
와 같은 참조 설정을 추가하여 제약을 추가할 수 있음
회고
- 오타 방지
- 이번 태스크에서 가장 뼈아픈 실수였다. 누가 그런것 같다. 코딩에서 실수를 줄이기 위해선 오타를 줄이는게 가장 빠르다고...
- 타자 빨리치면 멋있어 보이고 전문적으로 보인다고 흔히 생각한다. 반은 맞고 반은 틀린것 같다. 오늘같은 일이 생기면 전문적이고 뭐고 그냥 초보자다..
- 천천히 꼼꼼히 치거나, 복사, 붙여넣기를 애용하는 것도 필요하다. → 개발과정에서 충분히 테스트 해보자!
- 당황하지 말기
- 당황하면 긴장하고 손이 떨리기 마련이다. 가장 중요한 것은 침착함을 잃지 않는 것이다.
- 오히려 천천히 가는 것이 빠를 수도 있다. 차라리 천천히 타이핑하자
- 최대한 개발서버에서 테스트 해보기
- 항상 회고에 나오는 얘기이다. 충분히 테스트를 해보았다 싶다가도 꼼꼼히 생각하지 못해서 곧바로 운영서버에서 연속적으로 돌려야 하는 상황이 발생... 최대한 동일한 시나리오를 개발 서버에 제공하여 예상하지 못한 흐름을 만들지 말자...
- 개발 서버에서 충분히 여러 기능을 테스트 해보자
- 체크리스트 충분히 활용할것!
- 체크 리스트를 꼼꼼히 작성하여 사전에 고려하지 못한 내용이 있지는 않은가 확인해보는 과정이 필수적이다. 귀찮아도 만들어서 두세번 확인하고 개발 서버에 적용하면서 가이드라인을 최적화 하자!