django를 다루다 보면 migration을 하게 되는데요. 문득 궁금해 진 것이 하나 있었습니다. migration 기록은 어디에 저장하는 것일까요? 그래서 테스트 용으로 migrateTest 프로젝트를 만들었습니다.

 

 

 그냥 django 빈 프로젝트입니다. 바꾼 설정은 migrateTest 패키지 밑에 있는 settings.py를 건드린 것 뿐입니다.

 

 이 부분을 건드려서, 접근할 데이터베이스에 대한 정보를 초기화 해 주었습니다.

 


 showmigrations 명령어는 마이그레이션이 적용된 부분인 경우 x 표시를 해 줍니다. 지금은 모두 적용이 되지 않은 상태입니다.

 

 

 이제 migrate 명령어를 이용해서, 마이그레이션 파일에 있는 것들을 모두 적용해 보겠습니다.

 

 그 후에, 다시 showmigrations를 입력해 보면, 꽤 많은 것들이 적용되었음을 볼 수 있습니다. 이제 postgres에 접속해서 확인해 보겠습니다.

 


 마이그레이션 결과, 복수 개의 테이블이 생성되었는데요. 이 중 django_migrations 테이블을 보겠습니다.

 

 명령어는 요래 입력하시면 됩니다. 그러면, 이 테이블에 있는 전체 데이터가 보일 겁니다.

 

 id, app, name, applied가 있는데요. app과 name이 중요합니다. 각각 django의 app 이름, 마이그레이션 파일과 대응됩니다. 

 

 

 저는 migrate --fake admin zero를 입력해서, app admin 아래에 있는 마이그레이션을 unapply 되었다고 하겠습니다. 그 후에 showmigrations 명령어를 입력해서 적용 상태를 보겠습니다.

 

 

 그러면 admin 밑에 있는 친구들이 x 표시가 되어 있지 않았음을 알 수 있어요.

 

 

 django_migrations 테이블에는 어떻게 반영이 되어 있을까요? app이 admin인 것을 검색해 보겠습니다.

 

 없습니다. app 이름이 admin인 것의 마이그레이션은 적용이 안 된 걸로 fake 쳤기 때문입니다.

 

 

 이 상태에서, migrate를 적용해 봅시다. 그러면, Traceback이 뜨는데요. 이는, 이미 relation이 있기 때문입니다. 말로만 듣던 충돌이 발생했습니다.

 

 


 실험이니까 할 수 있는, django_migrations 테이블에 있는 내용들을 모두 삭제하면 어떻게 될까요?

 

 

 showmigrations 테이블을 보면, admin이랑 auth 등에 있는 모든 마이그레이션 앞의 x 표시가 없어졌음을 볼 수 있습니다. 이 과정에서 마이그레이트를 시도하면 오류가 뜰 텐데요. fake 옵션을 주었는데도 왜 안 되는지는 충돌 때문이지만 다음 글에서 천천히 이야기 해 보도록 하겠습니다. 이 글에서는 django에서 migration 기록이 어디에 저장되는지 알아보았습니다.