마이그레이션은 데이터베이스 스키마의 변경을 추적하는 형상 관리 시스템이다. 이것을 통해 장고에서 변화된 모델은 데이터데베이스의 스키마로 이주된다.
manage.py를 통해 두 가지 단계를 거치는데 makemigrations와 migrate이다.
단어가 헷갈리기 마련인데 동사 명령어임으로 기억하자. makemigrations은 여러 마이그레이션을 수행하기 때문에 복수형이다.

makemigrations

이 명령어는 코드 상의 변화를 마이그레이션 파일로 기록하며, 커밋과 유사하게 작동한다.
Django 프레임워크는 models.Model을 상속받은 클래스들의 변경 사항을 자동으로 탐지하고 기록한다.

모델 코드에 변화가 발생하면 makemigrations를 실행하여 데이터베이스에 적용할 마이그레이션 파일을 생성한다.
이 파일들은 각 앱의 migrations 폴더에 저장되며, 이전 파일들과 연계하여 변화를 체인처럼 기록한다.
현재 파일만으로는 전체 스키마 구조를 완전히 표현할 수 없으며, 파일이 순차적으로 누적되어 스키마를 형성하게 된다. 따라서 중간의 파일이 누락되면 마이그레이션 프로세스가 중단될 수 있다.

마이그레이션을 롤백하는 과정은 현재 스키마에서 이전 마이그레이션 포인트로 역순으로 적용하는 방식으로 이루어지기 때문에, 마이그레이션 파일을 롤백 전에 삭제해서는 안된다.

migrate

migrate 명령어는 마이그레이션 파일들을 데이터베이스에 적용하는 과정이다.
이 과정은 마지막으로 적용된 마이그레이션부터 최신 마이그레이션까지 순차적으로 진행된다.
DBMS를 변경할 경우, migrate를 실행하여 모든 마이그레이션을 처음부터 새로 적용하면 같은 스키마가 생성된다.

이 과정은 데이터베이스의 django_migrations 테이블에도 기록된다. 이 테이블은 스키마 변화를 추적하고 적용하는 데 사용된다.
따라서 로컬 마이그레이션 파일을 직접 수정하면 django_migrations 테이블과의 불일치가 발생하여 의존성 문제를 일으킬 수 있다.
반대로, 데이터베이스 테이블을 직접 수정할 경우에도 모델과의 동기화가 해제되어 마이그레이션 과정에서 충돌이 발생할 수 있다.

데이터가 삽입된 후 참조 무결성 제약이 추가되면, 이로 인해 발생할 수 있는 문제가 상당히 복잡해진다.
python manage.py migrate myapp zero 명령을 통해 모든 마이그레이션을 롤백할 수 있지만, 의존성 문제로 인해 이 과정이 자동으로 처리되지 않을 때 오류가 발생할 수 있다.
이 경우 데이터베이스를 삭제하는 것까지 고려해야 한다.
git파일과 마찬가지라 생각하고 마이그레이션파일의 raw수정은 하지말자…