사건의 발단
오후 2시에 있을 캡스톤 디자인 최종 발표를 위해 밤을 새던 중, 마지막 기능인 "알람" 기능을 만드려고 준비하고 있었다.
새로운 데이터 테이블이 필요해서 "UserAlarm" 이라는 model과 admin을 추가하고 마이그레이션을 진행하기로 했다.
어드민 페이지에 잘 생성된 것까지 확인하며 깃허브에 바로 커밋하였다.
그리고 기능을 만들기 위해 어드민 페이지에서 데이터 값을 추가하려고 하는데....
황당했다.
다른 기능적인 결함이 아니라 기초적인 db 연동이 안 된다는 점이 프로젝트 발표 전날에 생기는 게 말이 안 됐기 때문이다. 너무 어이가 없고 당황해서 makemigrations와 migrate를 계속 반복하였지만, 뭐가 잘 못 된건지 전혀 감이 안 잡혔다.
그래서 결국 다른 사람들이 해결한 방법들을 사용해보기로 했다.
시도한 방법들
1. --run-syncdb
migrate을 진행할 때, --run-syncdb를 뒤에 붙이면 된다고 한다.
해당 명령어는 DB에 테이블을 다시 만들어주는 명령어라고 한다.
python manage.py migrate --run-syncdb
이 후 다시 runserver를 하였지만 여전히 테이블은 생성되지 않았다.
2. Reset Migration
이번에는 기존 마이그레이션 기록을 리셋하고 다시 마이그레이션을 진행해보았다.
python manage.py migrate --fake {리셋하려는 app} zero
python manage.py makemigrations
python manage.py migrate
그러나 여전히 테이블 생성은 되지 않았다.
3. migrate가 잘 되었는가?
다른 사람들도 결국 위의 내용과 비슷한 말들을 하길래 결국 직접 마이그레이션 파일을 뜯어 보기로 하였다.
장고에는 ORM이란게 있어서, 파이썬 코드와 데이터베이스를 쉽게 연동할 수 있다.
장고는 이 연동을 위해 "마이그레이션"이라는 것을 적용한다.
실제 데이터베이스에도 이 마이그레이션을 저장하는 테이블이 따로 존재한다.
예전에 ai 기능을 구현하던 중, 서버가 터져서 다시 복구한 적이 있다.
이 때, db를 다시 생성하느라 장고에 생성된 마이그레이션 폴더를 삭제한 적이 있다.
하지만 그때는 마이그레이션 로그가 db에도 저장된다는 점을 몰랐다.
위 테이블을 보면 알겠지만 각 app의 첫 마이그레이션 이름은 "0001_initial"로 고정된다.
그래서 새로운 마이그레이션을 생성 후, migrate해도 db에서는 이미 진행한 마이그레이션으로 판단을 해서 새로운 테이블이 생성되지 않은 것이다.
그러면 db에 저장된 마이그레이션 로그를 삭제하면 되지 않을까?라고 생각도 잠깐 하였는데, user를 참조하는 다른 마이그레이션이 존재해서 이 dependency를 최대한 안 건드리는 방향으로 해결하기로 하였다.
결국 나는 새로운 마이그레이션을 인식할 수 있도록 마이그레이션 폴더를 삭제하지 않고, model.py에 새로운 진행 사항들을 추가하기로 하였다.
나 같은 경우에는 model명과 db_table명을 변경하여 migration을 인식하도록 하였다.
하지만 이렇게만 진행한다면 문제가 migrate 자체가 안 될 수 있다.
왜냐하면 존재하지도 않는 UserAlarm 테이블을 삭제하려고 하기 때문이다.
따라서 직접 migrations 코드로 들어가서 Delete model Useralarm이라는 코드를 삭제해보자
그 결과 테이블이 생성되어 잘 실행되는 것을 확인할 수 있다.
번외
그런데 데이터를 추가하려고 user alarm 추가 버튼을 눌렀으나 다른 column들이 생성되지 않았다.
캡스톤 최종 발표하는 당일에!!!!!
온 세상 억까가 다 나한테 왔다는 느낌을 받았지만 곧 내 멍청함때문이라는 것을 알게 되었다.
왜 그랬는 지는 모르겠는데 뒤에 콤마(,)를 붙여서 다른 column들을 인식하지 못 한 것이었다.
결국 마이그레이션 파일을 보고 왜 잘 못 되었는 지를 알게 되었지만 원인을 찾으려고 1시간을 투자한 거 같다.
진짜 능지 무엇
'이슈 > Django' 카테고리의 다른 글
[Django] drf-jwt를 이용한 로그인 토큰 발급받기 (2) | 2023.10.09 |
---|