장고
- 파이썬 기반의 웹프레임워크
- MVC 패턴으로 이루어져 있음
프레임워크
- 자주 사용되는 코드를 체계화하여 쉽게 사용할 수 있도록 도와주는 코드 집합
- 라이브러리와 혼동될 수 있지만 좀 더 규모가 므고 프로젝트의 기반이 됨
- 건축에 비유하면 구조를 만드는 골조가 프레임워크라면 그 외 자재들이 라이브러리가 됨
- 웹 프레임워크: 웹개발에 필요한 기본적인 구조와 코드(클래스,함수 등)가 만들어져 있음
Q1. 장고를 사용하신 이유는?
- 파이썬 기반이여서
- 참고할 레퍼런스가 많아서
Q2. 로컬 DB와 서버 DB의 구조 차이로 인한 migrate가 conflict 날 경우 해결법은?
Django 를 사용해 본 경험이 있다면 로컬 디비와 서버 디비에 구조차이로인한 migrate가 컨플릭트 날경우 어떻게 해결하는가
구조차이로 인한 migrate 컨플릭트는 당연한 결과입니다.
이를 해결하기 위해서고려해야 할 부분들이 있습니다.
일단 로컬디비에서 수정이 생겼다면 테스트를 거쳐 이상이 없음을 확인하고
서버와 동기화를 해야합니다.
서버와 동기화한다는 것은 추가적으로 수정한 부분을 서버에 반영하는 것을 말합니다. 일단 첫번째 방법은 서버 DB를 리셋하고 로컬 DB 구조를 엎는 방법이 있을거고요. 이때 서버에 디비 데이터들을 백업을 해놓아야 합니다. 그러나 이 방법은 서버 DB가 돌아가고 있다는 전제라면 불가능하니 말이 안될 것 같네요...
두 번째 방법은 아예 서버 DB를 복사해서 로컬 DB와 동기화 한후 테스트까지 거쳐서 디비를 옮기는 방법이 있을 것 같습니다.
새로 DB 복사본을 만들어서 수정본을 반영하고 다시 현재 서버 DB와 바꾸는 뭐 그런식의 대처가 가능할 것 같습니다.
세번째 방법은 구조차이가 난 문제의 schema나 migration 파일을 확인해서
해당 부분만 수정, 반영하는 방법이 있을 것 같습니다.
그러나 이 방법도 기존에 백업해 둔 파일이나 위 방식을 사용하여 하는 것이 안전하고 시간도 위 방법보다 오래 걸릴 수 있어 좋은 방법은 아니라고 판단됩니다.
[tip]
makimigrations는 장고에서 제공하는 모델의 변경사항들을 감지하고 기록하는 역할을 하며 migrate는 그러한 기록된 파일들과 설정값들을 읽어서 그 변경사항을 db에 저장하는 역할을 한다.
makemigrations 이후에는
migration 폴더를 확인하는 습관을 갖는게 좋다.
DB는 중요하기 때문에 무엇이 수정되었는지 다시 한번 확인하는 습관.
makemigrations [app-name] 처럼 app 이름을 명시하는 것이 좋다. (예상치 못한 migration을 방지)
showmigrations 를 통해서 적용 상태를 조회할 수 있다. [x] : 적용 후 []: 적용 전
실제 DB에는 sql 쿼리로 명령이 전달이 된다. migration 파일은 쿼리는 아니다. 따라서 sqlmigrate 명령을 통해 sql로도 확인하는 습관이 필요하다.
이미 적용한 migration 파일은 절대로 지우면 안된다.
프로젝트/앱 생성 후 처음 migrate 할 때는 app 이름을 명시하지 않는다. 이는 장고 기본 앱에, 여러 앱에 걸쳐서 적용할 migrate가 있기 때문이다.
no such table, column 등의 오류는 migration 관련 문제이다.
일반적인 migrate
$ python manage.py migrate
미적용 마이그레이션 파일 부터 최근 마이그레이션 파일까지 Forward 마이그레이션을 순차적으로 수행한다.
특정 파일지정을 통한 migrate
$ python manage.py migrate <마이그레이션 파일명>
지정한 마이그레이션 파일이 현재 적용된 마이그레이션 파일 보다
이후라면, Forward 마이그레이션 을 순차적으로 진행
이전이라면, Backward 마이그레이션 을 순차적으로 진행 roll-back
Django 기본 05 - Migration
AskDjango 수업을 듣고 중요한 내용을 정리하였습니다. 가이드문서 모델 변경내역 히스토리 관리 모델의 변경내역을 DB Schema (데이터베이스 데이터 구조)로 반영시키는 효율적인 방법을 제공…
wayhome25.github.io
추가적으로 프로젝트 협업간에 migration file의 충돌로 문제가 될 소지가 있을 경우 어떻게 해야할까요?
Stackoverflow에 좋은 질문이 있어 가져와 봤습니다.
나는 현재 개발부서에서 일하고 있는데 내 브랜치가 언젠가는 마스터로 머지 되어야 할 것이다.내 브랜치에 최대 20개의 마이그레이션 파일이 있고 현재 마스터에 대한 마이그레이션 파일도 거의 동일하다. 두 branch모두 마이그레이션해야 하는데, 다음과 같이동일한 접두사를 가진 마이그레이션 파일이 존재한다.
(ex 0003_auto)
즉, 접두사가 동일한 마이그레이션 파일이 있는 경우 이를 처리하는 가장 좋고 안전한 방법은 무엇일까?
일단 내 migration file들을 모두 지우고 code를 merge한다.
이후 makemigation과 migrate를 실행하여 오직 하나의 migration file만을 만든다.
두 번째는 merge 라는 명령어를 주어 Django에게 migration file을 merge 요청한다. meke migrations --merge
이것을 처리하는 가장 좋은 방법이 무엇인지 알고 싶다. 일반적으로 충돌을 올바르게 병합하고 모든 모델 업데이트와 함께 프로젝트의 새 버전을 가져오려면 어떻게 해야하는가?
- 마이그레이션 시 우발적인 병합 충돌을 방지하기 위해 Git에 데이터베이스와 직접 관련이 있는 마이그레이션 파일이나 마이그레이션 폴더를 푸시하지 않는 것이 좋다.
- Django Docs : 마이그레이션은 버전 제어에 저장되기 때문에 사용자와 다른 개발자가 동시에 동일한 앱으로 마이그레이션을 수행하여 동일한 수의 마이그레이션을 두 번 수행하는 경우가 종종 발생할 수 있습니다. 그러나 걱정하지 마세요. 개발자의 참조를 위해 숫자(0001...)가 있을 뿐이며, Django는 각 마이그레이션이 다른 이름을 가지는 것만 관리한다.
-프롬프트 없이 모든 마이그레이션을 자동으로 병합할 수 있는 명령어가 있다.(CI pipeline에 적합함)
python manage.py makemigrations --merge --noinput
python manage.py migrate
아래는 merge명령어를 주면 다음과 같이 묻습니다.
python manage.py makemigration --merge
Merging nested
Branch 0002_auto_20191021_0851
- Rename field startTime on match to start_time
Branch 0002_auto_20191021_0856
- Rename field startTime on match to start_time
Merging will only work if the operations printed above do not conflict
with each other (working on different fields or models)
Do you want to merge these migration branches? [y/N] yes
migrations
│ │ ├── 0001_initial.py
│ │ ├── 0002_auto_20191021_0851.py
│ │ ├── 0002_auto_20191021_0856.py
├── 0003_merge_20191030_0922.py
0003 merge file이 생성됩니다.
- TDD에대하여 말하라
Reference
