Cf. 불필요한 마이그레이션 정리하기

참고: DB는 migration내용을 어떻게 기록하는 가 =>  'migrate --fake' 를 이해하는 데 도움이 된다
2021.10.27 - [Web Project/Morning_diary] - 1. User Model을 AbstractUser Model로 바꾸기

django에서 DB를 다루다보면 스키마 수정을 잘못해서 되돌리고 싶은 경우가 있다. 되돌리는 방법은 두가지가 있다.

 

ⓐ 수정하는 migration을 하나 더 쌓는다. (불필요한 migration layer가 쌓인다)

ⓑ 잘못 수정한 migration을 제거하고 다시 쌓기 시작한다. 

 

migration layer가 불필요하게 쌓이고 나면 앱이 무거워지고, 이는 CI에서 비효율을 초래하기 때문에 ⓑ 방법을 선택하는 것이 좋아보일 수 있다.

1. ⓑ 방법에 대해서 알아보자. 

1) migrate app_name migration_number (ex."migrate poll_app 002") 명령어를 사용하여 DB 스키마 되돌리기
2) 되돌릴 migration 파일 삭제 (ex. 003 migration 삭제)
3) 새롭게 makemigrations & migrate

 

2. ⓑ 방법을 사용하다보면 이런 문제가 생길 수 있다.

[001에 존재하던 필드를 002 migration 때 지웠던 case] 이런 경우 하나씩 직접 손 봐주면서 되돌아가야한다. 

 

3. 상기한 문제는 되돌려야하는 migration이 두개 이상일 때 큰 문제가 된다. 번거로운 문제는 둘째 치고, 하나씩 손봐주면서 되돌아가다가 데이터가 소실될 수 있기 때문이다.

 

4. 이런 문제 때문에 (데이터가 소실되어도 괜찮은) development 과정이 아니라면, ⓐ 방법을 선택해야한다. 

 

5. 그렇다면 ⓐ 방법의 문제점(불필요한 migration layer가 쌓이는 것)은 어떻게 해결해야 할 수 있을까? 이것에 대한 좋은 글이 있다.

 

<migration을 정리하는 방법에 대한 글>
https://simpleisbetterthancomplex.com/tutorial/2016/07/26/how-to-reset-migrations.html

How to Reset Migrations

 

6. 위 게시글을 올린 사람은 목적 성취를 위해 'migrate --fake' 명령어를 이용하였는데 이게 무엇을 의미하는 걸까? 공식문서에는 추상적인 설명만 있어서 와닿지가 않는다.

추상적인 django 공식 글

 

7. 검색을 통해 --fake의 구체적인 원리에 대해 알게 되었다.

 

출처: https://it-eldorado.tistory.com/151

 

좋은 정보 제공해주신 분께 정보 찾은 방법에 대해 질문하였다.

 

8. 즉 최종 DB 스키마가 변하지 않는다는 가정하에서 이렇게 생각할 수 있다.

"migrate를 되돌린 다음에 다시 새롭게 migrate하는 것" => "복잡하게 쌓여있는 migration 기억을 몇개의 단순한 기억으로 바꿔치기 하는 것"

이 생각을 한번 더 연장하여 다음과 같은 방법을 사용한 것이다.

"복잡하게 쌓여있는 migration 기억을 몇개의 단순한 기억으로 바꿔치기 하는 것" => "DB에 저장되어 있는 migration layer 정보를 '--fake'를 이용하여 지우고, 다시 새롭게 migarte('--fake-initial' 이용) 하여 단순한 migration layer 정보로 바꾸는 것"

 

9. 보다 자세하고 명쾌한 내용은 여기서 확인할 수 있다. 

 

https://it-eldorado.tistory.com/151

[오픈갤러리] Django 서버 정리 작업 ④ - 마이그레이션 파일 정리