본문 바로가기

레퍼런스/장고 튜토리얼

장고(Django) 모델을 활성화 하는 법

약간의 모델 코드는 장고에게 큰 정보를 주는 셈입니다. 모델 코드와 함께라면, 장고는 이런 걸 할 수 있어요 :

 

  • 이 앱을 위해 데이터베이스 스키마(CREATE TABLE 구문)를 만드는 것.
  • 질문선택 오브젝트에 접근하기 위한 파이썬 데이터베이스 접근 API를 만듭니다.

 

철학

장고의 앱은 "pluggable"입니다 : 앱을 여러 프로젝트에 사용하거나 앱을 나눌 수 있고 장고 설치에 연관되지 않았기 때문에 앱을 배포할 수도 있습니다.

 

앱을 프로젝트에 포함하기 위해서는 INSTALLED_APPS 설정안의 configuration 클래스를 레퍼런스에 추가해야 합니다. polls/apps.py 파일 안에 PollsConfig 클래스가 있기 때문에 dotted path로는 'polls.apps.PollsConfig'로 표기합니다. chem/settings.py 파일을 수정해서 dotted path를 INSTALLED_APPS 설정에 추가해줍니다. 아래와 같습니다 :

 

# chem/settings.py

INSTALLED_APPS = [
	'polls.apps.PollsConfig',
    	'django.contrib.admin',
    	'django.contrib.auth',
    	'django.contrib.contenttypes',
    	'django.contrib.sessions',
    	'django.contrib.messages',
    	'django.contrib.staticfiles',
]

 

이제 장고는 polls 앱이 포함된 걸 압니다. 다른 커맨드를 실행해보죠 : 

 

$ python3 manage.py makemigrations polls

 

저는 이미 migrations를 실행시켜 놓은 상태라 그런지 아무런 변화가 없는 것으로 뜹니다.

 

 

makemigrations를 실행함으로써 장고에게 모델의 변화를 알려줍니다(이 경우에는 새로운 모델을 만든 셈이죠). 그리고 변경사항을 migration으로 저장하고 싶다고 한 것입니다.

 

Migrations는 장고가 여러분의 모델을 어떻게 저장하는지를 보여줍니다(즉, 여러분의 데이터베이스 스키마에 어떻게 저장되는 지입니다) - 저장 디스크의 파일일 뿐인데요. 여러분이 원한다면 새 모델의 migration을 읽는 것이 가능합니다. polls/migrations/0001_initial.py가 바로 그 파일이죠. 장고가 migration을 만들 때마다 읽을 필요는 없지만 여러분이 원할 때마다 수동으로 변화를 줄 수 있게 설계돼 있습니다.

 

여러분의 데이터베이스 스키마를 자동으로 다룰 수 있게 하는 커맨드가 있습니다 - migrate라고 불리는 것인데요. sqlmigrate 커맨드는 migrations 이름을 가져가고 그 SQL을 돌려줍니다.

 

$ python3 manage.py sqlmigrate polls 0001

 

 

위와 같은 결과가 나오는군요.

 

아래의 사항들을 참고하세요 :

 

  • 여러분이 사용하시는 데이터베이스에 따라서 결과값은 달라질 수 있습니다.
  • 테이블 이름은 앱(polls)과 모델의 소문자에 따라서 자동으로 생성됩니다 - 아까 만들었던 questionchoice 모델입니다(override 가능합니다).
  • Primary Key(IDs)는 자동으로 생성됩니다(override 가능합니다).
  • 설계된 대로 장고는 Foreign Key 이름을 "_id" 형태로 추가합니다(당연히, override 가능합니다).
  • Foreign Key 관계는 FOREIGN KEY 제한을 통해서 명백해집니다.
  • 여러분이 사용하시는 데이터베이스에 따라서 필드 타입이 변할 수 있습니다. auto_increment (MySQL), serial (PstgreSQL), 또는 integer primary key autoincrement (SQLite)를 사용해서 자동으로 다뤄질 수 있습니다. 예를 들어, 큰 따옴표나 작은 따옴표를 사용하여 필드 이름을 인용할 때도 마찬가지입니다.
  • sqlmigrate 커맨드는 여러분의 데이터베이스에서 migration을 실제로 실행하지 않습니다. SQL 장고가 어떤 것이 필요한 지 화면에 보여주는 것일 뿐입니다. 장고가 어떤 동작을 할 지, 데이터베이스 관리자가 SQL 스크립트에 변화를 준다면 확인할 수 있습니다.

 

python3 manage.py check;문을 사용해서 확인할 수 있습니다. migrations와 데이터베이스를 건드리지 않고 여러분의 프로젝트에 있는 문제를 검사할 수 있습니다.

 

이제 migrate를 실행해서 여러분의 데이터베이스에 모델 테이블을 생성합니다.

 

$ python3 manage.py migrate

 

migrate 커맨드는 적용되지 않은 모든 migrations를 적용합니다 (장고는 데이터베이스에 있는 특별한 테이블인 django_migrations를 찾아내서 적용합니다).  여러분이 스키마에 바꾼 모든 변화들을 싱크로나이징합니다.

 

Migrations는 새로운 테이블과 데이터베이스를 기존의 것을 삭제하고 새로 만들지 않아도 되기 때문에 프로젝트를 개발하는 시간이 길어질수록 매우 강력한 도구입니다. 데이터베이스를 업그레이드한다고 생각하면 됩니다.

 

지금까지는 이 3단계를 기억해주시면 됩니다.

 

  • 모델을 변경하고(models.py)
  • python3 manage.py makemigrations로 migrations를 생성하고
  • python3 manage.py migrate로 데이터베이스의 변경을 적용합니다.

저렇게 migrations의 생성과 적용이 분리돼 있는 이유는 여러분의 버전 관리 시스템으로의 migrations를 커밋하고 여러분의 앱에 넣기 때문입니다. 이게 여러분의 개발만 쉽게 하는 것이 아니라, 다른 개발자들에게도 매우 유용하게 해 줍니다.