Django Tutorial Part.2

BLAKE KIM·2020년 7월 28일

데이터베이스 설치

DATABASES default 값

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': os.path.join(BASE_DIR, 'db.sqlite3'),
    }
}

ENGINE --
'django.db.backends.sqlite3',
'django.db.backends.postgresql',
'django.db.backends.mysql',
'django.db.backends.oracle'

NAME --
데이터베이스의 이름.
만약 SQLite를 사용 중이라면, 데이터베이스는 당신의 컴퓨터의 파일로서 저장됩니다. 이 경우, NAME 는 파일명을 포함한 절대경로로 지정해야 합니다. 기본값은 os.path.join(BASE_DIR, 'db.sqlite3')로 정의되어 있으며, 프로젝트 디렉토리 내에 db.sqlite3 파일로 저장됩니다.

SQLite 이외의 데이터베이스라면 만약 SQLite 이외의 데이터베이스를 사용하는 경우, 이 시점에서 데이터베이스를 생성해야 합니다. 데이터베이스의 대화형 프롬프트 내에서 "CREATE DATABASE database_name;" 명령을 실행하면 됩니다.

또한, mysite/settings.py 에 설정된 데이터베이스 사용자가 "create database" 권한이 있는지도 확인해 봐야 합니다. 튜토리얼을 진행하며 필요한 경우 테스트 데이터베이스를 자동으로 생성할 수 있도록 해줍니다.

SQLite를 사용한다면 아무것도 미리 생성할 필요가 없습니다. 데이터베이스 파일은 필요할 때마다 자동으로 생성됩니다.

mysite/settings.py를 편집할 때, 당신의 시간대에 맞춰 TIME_ZONE 값을 설정

INSTALLED_APPS에 대해 언급하자면, 이 파일은 현재 Django 인스턴스에서 활성화된 모든 Django 어플리케이션들의 이름이 담겨 있습니다.

기본 INSTALLED_APPS

django.contrib.admin -- 관리용 사이트. 곧 사용하게 될 겁니다.
django.contrib.auth -- 인증 시스템.
django.contrib.contenttypes -- 컨텐츠 타입을 위한 프레임워크.
django.contrib.sessions -- 세션 프레임워크.
django.contrib.messages -- 메세징 프레임워크.
django.contrib.staticfiles -- 정적 파일을 관리하는 프레임워크.

데이터베이스 생성

python manage.py migrate

migrate명령은 INSTALLED_APPS setting을 살펴 보고 mysite/settings.py 파일에 있는 데이터베이스 설정에 따라서 모든 필요한 데이터베이스 테이블을 만든다. 데이터베이스 이동은 앱과 함께 이동한다.(나중에 살펴본다고 함)
각각의 이것이 적용되는 migration message를 보게 될 것이다고 함.

만약 어플리케이션을 따로 생성했다면 setting.py에 추가해야 한다.

모델 만들기

모델이란 부가적인 메타데이터를 가진 데이터베이스의 구조(layout)을 말한다.

모델(model)은 데이터에 관한 단 하나의, 가장 확실한 진리의 원천입니다. 이것은 당신이 저장하는 데이터의 필수적인 필드들과 동작들을 포함하고 있습니다. Django 는 DRY 원칙 을 따릅니다. 이 원칙에 따라 데이터 모델을 한곳에서 정의하고, 이것으로부터 자동으로 뭔가를 유도하는 것이 목표입니다.

반복하지 말 것(DRY): 고유한 개념 및 데이터는 단 한 번, 단 한 곳에 존재하는 것으로 족합니다. 중복성은 나쁜 것이고, 정규화는 좋은 것입니다. 그러한 이유로, 본 프레임워크는 최소한의 것들을 가지고 최대한의 것을 만들어내도록 합니다.

tutorial에서 만들게될 설문조사 어플리케이션에서는 두 가지 모델을 만들어야 한다. 질문과 선택. 질문 모델에는 질문과 발표 데이터가 있어야 한다. 선택 모델에는 두 가지 영역을 가진다. 텍스트와 투표 집계. 그리고 각 선택은 질문과 관련이 있습니다.

polls/models.py

from django.db import models

class Question(models.Model):
    question_text = models.CharField(max_length=200)
    pub_date = models.DateTimeField('date published')

class Choice(models.Model):
    question = models.ForeignKey(Question, on_delete=models.CASCADE)
    choice_text = models.CharField(max_length=200)
    votes = models.IntegerField(default=0)

각각의 모델은 django.db.models.Model의 서브클래스로 하는 class로 표현된다. 각각의 모델은 모델 안에서 데이터베이스 필드를 표현하는 많은 클래스 변수를 가진다.

데이터베이스의 각 필드는 Field 클래스의 인스턴스로서 표현됩니다. CharField 는 문자(character) 필드를 표현하고, DateTimeField 는 날짜와 시간(datetime) 필드를 표현합니다. 이것은 각 필드가 어떤 자료형을 가질 수 있는지를 Django 에게 말해줍니다.

각각의 Field 인스턴스의 이름(question_text 또는 pub_date)은 기계가 읽기 좋은 형식의 데이터베이스 필드 이름입니다. 이 필드명을 Python 코드에서 사용할 수 있으며, 데이터베이스에서는 컬럼명으로 사용할 것입니다.

Field 클래스의 생성자에 선택적인 첫번째 위치 인수를 전달하여 사람이 읽기 좋은 이름을 지정할 수도 있습니다. 이 방법은 Django 의 내부를 설명하는 용도로 종종 사용되는데, 이는 마치 문서가 늘어나는 것 같은 효과를 가집니다. 만약 첫번째 위치 인수를 사용하지 않으면, Django 는 기계가 읽기 좋은 형식의 이름을 사용합니다. 이 예제에서는, Question.pub_date 에 한해서만 인간이 읽기 좋은 형태의 이름을 정의한다.

몇몇 Field 클래스들은 필수 인수가 필요합니다. 예를 들어, CharField 의 경우 max_length 를 입력해 주어야 합니다. 이것은 데이터베이스 스키마에서만 필요한것이 아닌 값을 검증할때도 쓰인다.

Field 는 다양한 선택적 인수들을 가질 수 있습니다. 이 예제에서는, default 로 하여금 votes 의 기본값을 0 으로 설정하였습니다.

마지막은 ForeignKey 를 사용한 관계설정이다. 이 예제에서는 각각의 Choice 가 하나의 Question 에 관계된다는 것을 Django 에게 알린다. Django 는 다-대-일, 다-대-다, 일-대-일 과 같은 모든 일반 데이터베이스의 관계들를 지원한다.

모델의 활성화

모델에 대한 이 작은 코드가, Django에게는 상당한 양의 정보를 전달합니다. Django는 전달받은 정보를 가지고 앱을 위한 데이터베이스 스키마 생성(CREATE TABLE문)과 Question과 Choice 객체에 접근하기 위한 Python 데이터베이스 접근 API를 생성한다.

mysite/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',
]

앱을 현재의 프로젝트에 포함시키기 위해서는, 앱의 구성 클래스에 대한 참조를 INSTALLED_APPS 설정에 추가해야 한다. PollsConfig 클래스는 polls/apps.py 파일 내에 존재하므로 점으로 구분된 경로는 'polls.apps.PollsConfig'가 됩니다. 이 점으로 구분된 경로를, mysite/settings.py 파일을 편집하여 INSTALLED_APPS 설정에 추가하면 Django는 polls 앱이 포함된 것을 알게 된다.

python manage.py makemigrations polls

Migrations for 'polls':
  polls/migrations/0001_initial.py
    - Create model Question
    - Create model Choice

makemigrations를 실행시킴으로서, 모델을 변경시킨 사실과 이 변경사항을 migration으로 저장하고 싶다는 것을 Django에게 알려준다. migrations는 Django 저장소가 모델들을 어떻게 바뀌었는지 디스크에 파일로 저장한다. 읽고 싶다면 읽을 수 있지만 매번 그럴 필요는 없다. migration을 실행시켜주고, 자동으로 데이터베이스 스키마를 관리해주는 migrate 명령어가 있다.

python manage.py migrate

migrate 명령은 아직 적용되지 않은 마이그레이션을 모두 수집해 이를 실행하며(Django는 django_migrations 테이블을 두어 마이그레이션 적용 여부를 추적합니다) 이 과정을 통해 모델에서의 변경 사항들과 데이터베이스의 스키마의 동기화가 이루어집니다.

모델의 변경을 만드는 세 단계의 단계를 기억하자.

(models.py 에서) 모델을 변경합니다.
python manage.py makemigrations을 통해 이 변경사항에 대한 마이그레이션을 만드세요.
python manage.py migrate 명령을 통해 변경사항을 데이터베이스에 적용하세요.

Django 관리자 소개

관리자 사이트를 만드는 것에는 창의적일 필요없는 지루한 작업이다. 그렇기에 Django는 모델에 대한 관리용 인터페이스를 모두 자동으로 생성한다.

관리자 생성하기

python manage.py createsuperuser
Username: admin				# username 입력
Email address: admin@example.com	# email 입력
Password: **********			# 8자리 이상 패스워드
Password (again): *********
Superuser created successfully.		# Done


python manage.py runserver
# http://127.0.0.1:8000/admin/으로 접속하면 방금 생성한 관리자 계정을 통해 접속 가능하다.

관리 사이트에서 poll app을 변경 가능하도록 만들기

polls/admin.py

from django.contrib import admin
from .models import Question

admin.site.register(Question)

해당 파일이 위 내용을 추가하기 전에는 아래 사진에서 AUTHENTICATION AND AUTHORIZATION영역만 보였는데 추가한 후에는 POLLS영역이 추가되었다.

위 화면에서 Questions를 클릭하면 빈 목록이 나오고 그 화면에서 Add question을 누르면 아래와 같은 화면이 나온다.

테두리가 그려진 input영역은 모두 빈 화면으로 처음에 생성되고 각각의 영역에 직접 작성한 화면이다. Question text에는 What's up을, Date에는 옆의 Today를 누르면 오늘에 해당하는 날짜를 자동으로 넣어준다. Time도 옆에 Now를 누르면 현재 작성 시각을 입력해준다.

이 화면은 Question 모델에서 자동으로 생성된 것으로 모델의 각 필드 유형들은 (DateTimeField, CharField) 적절한 HTML 입력 위젯으로 표현된다. 필드의 각 유형들은 Django 관리 사이트에서 어떻게 표현되어야 할지 알고 있다.

여기서 Date published가 현재 날짜와 시간이 일치하지 않는다면 TIME_ZONE 설정을 빠뜨린 것일 수도 있다.