1. User Model을 AbstractUser Model로 바꾸기

배경: User Model은 커스터마이징이 어려워서 AbstractUser Model을 사용하는 것이 좋다
문제점: 한번 User로 Migration을 쌓고나면 나중에 꼬여서 수정이 어려운데, 이미 Migration을 쌓아놓은 상황
내 해결책: 아직 프로젝트 초반이니 마이그레이션을 전부 지우고 처음부터 다시 쌓자.

1. migration을 어떻게 지우지? (DB는 migration을 어떻게 기록하는가? 더보기 누르기)

 

그냥 DB를 지워버리면 되나?

migration 파일을 전부 지우면 되나?

showmigrations으로 조회되는 내용이 무엇을 의미하는지 알 수가 없으니 함부로 행동할 수가 없다.

 

 

그러다 검색과 몇가지 실험을 통해 DB와 migration의 관계에 대해 이해하게 되었다.

 

1. Migrate를 하면 DB는 스키마를 변경할 뿐 아니라 지금까지 적용된 Migration layer 에 대한 정보를 'django_migrations' TABLE에 저장한다.

 

https://docs.djangoproject.com/en/3.2/intro/tutorial02/

 

django_migrations TABLE에 지금까지 쌓아놓은 migration 정보를 DB가 나름대로 정리하고 있다

 

djago_migrations TABLE에 migration 정보가 차곡차곡 쌓여있는 모습

 

2. 이 TABLE의 record들은 곧 DB가 기억하고 있는 migration의 진행상황이다. 이는 showmigrations 앞부분의 [x] 마크로 나타난다. 이 정도까지 알고 있는 상태에서 다음 실험을 보면 DB와 migration의 관계를 이해할 수 있다.

 

2. 간단하게 DB를 지우면 된다.

    내 경우에 app 마이그레이션 파일들을 지울 필요는 없었는데, 최소한의 마이그레이션만 남기기 위해 한번 지워줬다.

    "불필요한 마이그레이션을 줄여서 앱을 가볍게 만드는 방법은 다음 링크를 참고하면 된다."

 

2021.10.28 - [Web Project/Morning_diary] - Cf. 불필요한 마이그레이션 정리하기

 

 

3. 다시 makemigration 하기 전에 AbstractUser를 선택하는 세팅을 하자

 

https://github.com/samon3869/Morning_diary/commit/b69e3bfe89721274861663d87f3523fd3a321103

 

4. makemigrations & migrate로 마무리하기

 

5. User Model과 AbstractUser Model을 사용하였을 때 실제로 DB가 어떻게 달라지는 지 확인

 

User Model을 적용하고 있던 처음 DB

auth_user, auth_user_groups, auth_user_user_permis.... 등이 확인된다

 

AbstractUser Model(Customizing) 적용하고 난 뒤 DB

diary_user, diary_user_groups, diary_user_user_permis.... 등이 확인된다