Tutorials
Tutoiral(2) 모델 & 관리자 사이트
Models and the admin site
튜토리얼(2)는 크게 네가지의 주제를 다룹니다.
- DB
데이터베이스를 설정합니다.
- Model
모델을 설정합니다.
- API
API (Application Programming Interface)를 다룹니다.
- Django admin
장고의 관리자 사이트를 다룹니다.
세부 항목은 다음과 같습니다.
2. Models and the admin site
2.1 Database setup
2.2 Creating models
2.3 Activating models
2.4 Playing with the API
2.5 Introducing the Django Admin
- Creating an admin user
- Start the development server
- Enter the admin site
- Make the poll app modifiable in the admin
- Explore the free admin functionally
우리는 데이터 베이스를 설정 한 후, 모델을 만들고, 그것이 동작하도록 할 것입니다. 그리고 API를 사용해보고, 장고의 관리자 사이트에 대해 알아보겠습니다.
2.1 Database setup
데이터 베이스를 설정합니다.
mysite폴더의 settings.py를 엽니다. settings.py는 일반적인 파이썬 모듈입니다. 이 모듈은 장고의 설정(settings)에 관여하는 모듈레벨의 변수들을 담고 있습니다.
보통 데이터베이스에는 SQLite가 사용됩니다. 데이터베이스가 낯설거나 단지 취미로 장고를 배우는 중이라면, SQLite를 추천합니다. SQLite는 파이썬 안에 이미 포함되어 있어서 따로 설치할 필요가 없습니다. 하지만 실제 프로젝트를 진행하려면 PostgreSQL 같은 강력한 데이터베이스가 필요합니다.
SQLite가 아닌 DB를 사용하고 싶다면 적절한 데이터베이스 바인딩 database bindings을 설치하고, settings.py 안의 DATABASE 항목을 수정합니다.
settings.py DATABASE 항목은 기본적으로 이렇게 기록되어 있습니다.
ENGINE
django.db.backends.sqlite3
NAME
os.path.join(BASE_DIR, 'db.sqlite3'
: SQlite를 사용하는 경우의 기본 값입니다. NAME은 파일의 이름을 포함하여 완벽한 경로로 기록되어야 합니다. 이 값을 통해 파일이 우리의 프로젝트 폴더에 저장됩니다.
다른 데이터베이스를 사용하는 경우 USER와 PASSWORD 그리고 HOST에 대한 설정이 추가되어야 합니다.
더 자세한 정보는 DATABASE 항목에 대한 설명서를 참고하세요. DATABASES
DATABASE 항목을 수정한 다음, TIME_ZONE 항목을 우리가 있는 지역에 맞게 수정합니다.
INSTALLED_APPS는 settings.py에서 가장 위에 위치해야 합니다. 이 장고 인스턴스(프로젝트)에서 이용할 수 있는 모든 앱(기능)이 이곳에 등록되기 때문입니다. 앱들은 다양한 프로젝트들에 중복하여 사용할 수 있습니다. 우리는 이 앱들을 묶거나 분배할 수 있습니다.
기본적으로 INSTALLED_APPS에는 몇가지 앱이 들어있습니다. 장고가 미리 가져온 것들입니다.
django.contrib.admin
관리용 페이지입니다. 곧 배우게 됩니다.
django contib.auth
시스템 인증
django.contrib.contenttypes
내용의 형식에 대한 프레임 워크
django.contrib.sessions
세션 프레임워크
django.contrib.messages
메시지 프레임워크
django.contrib.staticfiles
static 파일을 관리하는 프레임워크
위의 앱들은 최소한 하나의 DB 테이블을 가지고 있습니다. 우리도 앱을 만들려면 데이터베이스에 테이블이 있어야 합니다. 터미널에 아래와 같은 명령어를 입력하세요.
python manage.py migrate
이 migrate명령어는 settings.py의 INSTALLED_APPS 설정을 보고 데이터베이스에 대한 설정과 앱에서 만든 migrations를 따라 필요한 데이터베이스 테이블을 만듭니다. 각 migration이 적용될 때마다 메시지를 받게 됩니다. 흥미가 있다면 다른 터미널을 하나 더 열고 \dt (PostgreSQL), SHOW TABLES; (MySQL), .schema (SQLite), or SELECT TABLE_NAME FROM USER_TABLES; (Oracle) 를 입력해 보십시오.
migrate명령어를 실행한 다음 폴더를 확인하면 db.sqlite3 (또는 개별적으로 설정한 db) 파일이 만들어져 있습니다. 데이터베이스가 형성돼가는 것을 직관적으로 보고 싶다면, DB browser를 설치하는 것을 추천합니다.
2.2 Creating models
polls 폴더의 models.py 수정
이제 모델을 설정해보겠습니다. 모델은 부가적인 메타데이터와 함께 우리의 데이터베이스 레이아웃을 결정합니다.
하나의 모델은 단일하고 확정적인 신뢰할 수 있는 우리의 데이터 원천입니다. 모델에는 기본적인 필드와 우리가 저장한 데이터들의 행동이 포함됩니다. 장고는 DRY 원칙을 따릅니다. 목적은 우리의 데이터 모델을 한 장소에 정의하고 그것으로 부터 내용을 자동적으로 불러오는 것입니다.
장고의 모델은 루비 온 레일즈와 달리 migrations를 포함합니다. migrations를 모델에서 온전히 불러올 수 있고, 그것은 역사나 마찬가지이기 때문에 장고의 현재 모델에 데이터베이스 schema의 업데이트를 맞출 수 있습니다.
우리의 poll 앱의 polls/models.py에 Question 과 Choice 라는 모델을 만들어 줍니다. Question은 질문과 그 질문이 배포된 일자를, Choice는 선택지와 투표용 계정을 필드로 가집니다. 각각의 Choice는 Question과 연관이 있습니다.
모델에 대한 개념은 파이썬의 클래스로 표현됩니다. polls/models.py를 아래와 같이 수정합니다.
# 작성위치 : 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)
*ForeignKey의 F와 K는 대문자입니다!
*ON DELETE CASCADE는 이 필드에 참조된 값 들을 지워버리는 옵션입니다. model fiedls reference의 3.Relationship fields 에서 01.ForeignKey를 참고하십시오.
이 코드는 아주 간단합니다. 각각의 모델(Question과 Choice)은 클래스로 표현되어 있습니다. 좀 더 정확히 말하자면 django.db.models.Models의 하위클래스입니다. 장고(django)의 데이터베이스(db) 안 모델집합소(models)안에 있는 Models라는 클래스의 아래에 만들어진 클래스라는 의미입니다. (?)각각의 모델은 클래스 변수의 숫자를 가지고, 그 숫자는 그 모델의 데이터베이스 필드에 나타나있습니다.
각각의 필드는 필드 클래스의 인스턴스로 나타납니다. 예를 들어, character field의 인스턴스인 CharField, datetimes의 DateTimeField 등 입니다. 이 부분은 장고에게 각 필드가 가지고 있는 데이터가 어떤 타입인지 알려줍니다.
각 필드 인스턴스의 이름(예를들어, question_text 또는 pub_date)는 기계친화적 형식으로 만든 그 필드의 이름입니다. 우리는 이 값을 파이썬 코드에 사용할 수 있고, 데이터베이스에서는 이 값이 열(column)의 이름으로 사용됩니다.
우리는 첫번째 선택적 위치인수를 사람이 읽을 수 있는 이름을 지정하는 필드에 사용할 수 있습니다. 이것은 장고 내부에서 흔히 일어나는 일입니다. 문서에서도 마찬가지입니다. 만약 이러한 필드가 제공되지 않는다면, 장고는 기계친화적 이름을 사용합니다. 이 경우, 우리는 Question.pub_date와 같은 이름만을 사용할 수 있습니다. 위에서 예로 든 모델의 경우, pub_date외의 다른 모든 필드는 기계친화적 이름으로도 충분히 사용가능합니다.
몇몇 필드 클래스들은 인수가 필요합니다. 예를 들어, CharField는 우리가 max_length를 지정해주기를 원합니다. 이러한 인수 지정은 데이터베이스 schema에서만 일어나는 일은 아닙니다. 곧 검증과정에서도 사용하게 될 것입니다.
하나의 필드는 여러개의 선택적 인수를 가질 수도 있습니다. 위 예제의 경우, votes의 default값을 0으로 설정했습니다.
마지막으로, ForeignKey를 통해 관계가 정의됩니다. 이 ForeignKey는 장고에게 각각의 Choice가 하나의 Question과 연결된다고 알려줍니다. 장고는 모든 일반적 데이터베이스 연결관계를 지원합니다. (: many-to-one, many-to-many, one-to-one)
2.3 Activating models
모델안에 적어둔 아주 짧은 코드는 장고에게 엄청난 양의 정보를 줍니다. 그 코드를 통해 장고는 다음과 같은 일을 할 수 있습니다.
- 이 앱을 위한 데이터베이스의 얼개(schema)를 짭니다.(CREATE TABLE 문장이 하는 일입니다.)
- 파이썬의 데이터베이스에 접근할 수 있는 API를 만듭니다. 이 API는 우리가 models.py안에 작성한 Question과 Choice를 위해 사용됩니다.
하지만 우리가 우리의 프로젝트에 가장 먼저 알려주어야 하는 것은 따로 있습니다. polls 라는 앱을 설치했다는 것을 알려주어야 위에 적힌 일들이 진행될 수 있습니다.
장고의 앱들은 'pluggable' 합니다. 전선 플러그처럼 꽂았다 뽑았다 할 수 있지요. 하나의 앱을 여러개의 프로젝트에 사용할 수 있습니다. 앱들은 처음 만들어질 때의 장고 설치에 묶여있을 필요가 없고, 따라서 우리는 앱을 배포할 수 있습니다.
앱을 우리의 프로젝트에 포함시키기 위해서, 우리는 앱을 관리하는 관리파일에 앱에 대한 내용을 추가해야 합니다. mysite폴더의 settings.py안에 INSTALLED_APPS라는 항목이 있습니다. 이 곳에서 전체 프로젝트의 앱을 관리합니다.
polls앱을 관리하는 것은 polls폴더 안의 apps.py라는 파일입니다. 그 안에는 PollsConfig라는 클래스가 들어있습니다, 이 파일의 주소는 점을 이용하여 'polls.apps.pollsConfig' 라고 표현합니다.
mysite폴더 안의 settings.py 파일에 위의 주소를 추가합니다. INSTALLED_APPS 부분에 추가하면 됩니다. 이제 mysite/settings.py의 INSTALLED_APPS 부분은 다음과 같이 보일 것입니다.
# 작성위치 : 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',
]
*polls.apps.PollsConfig의 PollsConfig에서 P와 C는 대문자입니다!
*'polls'만으로도 등록이 가능합니다.
이제 장고는 polls라는 앱이 설치되었다는 것을 알게 되었습니다. 터미널에서 아래 명령어를 실행합니다.
$ python manage.py makemigrations polls
명령어를 실행하면 터미널 화면에 다음과 같은 내용이 나타날 것입니다.
Migrations for 'polls':
polls/migrations/0001_initial.py:
- Create model Choice
- Create model Question
- Add field question to choice
makemigrations를 실행하면, 우리는 장고에게 '모델에서 뭔가를 수정했어' 라고 알려주는 것입니다. 이 경우 그 수정사항은 새로운 뭔가를 만든 것이지요. 수정사항은 migration으로 저장해 두어야 합니다.
migrations는 장고가 우리의 모델 수정사항을 저장하는 방식입니다. (따라서 우리의 데이터베이스 얼개도 영향을 받습니다.) migrations는 그저 디스크 위에 올라간 파일일 뿐입니다. 우리는 우리의 새로운 모델에 대한 이 파일 내용을 polls/migrations/0001_initial.py에서 읽을 수 있습니다. 새로운 파일이 만들어질 때마다 그것을 확인하지 않아도 됩니다. 하지만 그 파일은 사람이 읽을 수 있도록 쓰여지기 때문에, 우리가 원한다면, 이 파일을 통해 장고의 바뀐 점들에 대해 조정할 수 있습니다.
migrations를 실행하고 우리의 데이터베이스 얼개를 자동으로 수정하려면 명령어를 하나 더 입력해야 합니다. migrate라는 명령어입니다. 하지만 이 명령을 내리기 전에 확인해야 하는 것이 있습니다. 어떤 SQL이 이 migration을 구성하고 있나요? sqlmigrate 라는 명령어와 migration이름을 함께 입력하면 그것의 SQL에 대해 알 수 있습니다.
*SQL : Structured Query Language, 관계형 데이터베이스 관리시스템(RDBMS)의 데이터를 관리하기 위해 설계된 특수목적 프로그래밍 언어)
$ python manage.py sqlmigrate polls 0001
이 명령어를 입력하면 아래와 같은 내용을 보게 될 것입니다. (아래의 내용은 읽기 편하도록 재조정하였습니다.)
BEGIN;
--
-- Create model Choice
--
CREATE TABLE "polls_choice" (
"id" serial NOT NULL PRIMARY KEY,
"choice_text" varchar(200) NOT NULL,
"votes" integer NOT NULL
);
--
-- Create model Question
--
CREATE TABLE "polls_question" (
"id" serial NOT NULL PRIMARY KEY,
"question_text" varchar(200) NOT NULL,
"pub_date" timestamp with time zone NOT NULL
);
--
-- Add field question to choice
--
ALTER TABLE "polls_choice" ADD COLUMN "question_id" integer NOT NULL;
ALTER TABLE "polls_choice" ALTER COLUMN "question_id" DROP DEFAULT;
CREATE INDEX "polls_choice_7aa0f6ee" ON "polls_choice" ("question_id");
ALTER TABLE "polls_choice"
ADD CONSTRAINT "polls_choice_question_id_246c99a640fbbd72_fk_polls_question_id"
FOREIGN KEY ("question_id")
REFERENCES "polls_question" ("id")
DEFERRABLE INITIALLY DEFERRED;
COMMIT;
다음 내용을 주의하십시오.
정확한 결과(output)는 우리가 사용하는 데이터베이스에 따라 다를 수 있습니다. 위의 예시는 PostgreSQL을 기반으로 하고 있습니다.
테이블의 이름은 앱의 이름(여기서는 polls)과 조합되어 자동으로 만들어집니다. 위 내용을 보면
CREATE TABLE "polls_choice"또는CREATE TABLE "polls_question"이라는 부분을 볼 수 있습니다. 이처럼 테이블의 이름은앱 이름_필드이름으로 자동생성되며, 원한다면 수정할 수도 있습니다.- Primary key(=ID)들은 자동으로 추가됩니다. 위 내용을 보면 각 테이블 마다 우리가 따로 기록하지 않았던 "id"필드가 생기며, 그 필드에 PRIMARY KEY속성이 붙은 것을 볼 수 있습니다. 원한다면 수정할 수 있습니다.
- 관습적으로 장고는 foreign key의 필드 이름에 "_id"를 추가합니다. (밑에서 네번째 줄)역시 원한다면 수정할 수 있습니다.
- 이하 생략
만약 관심이 있다면, python manage.py check 명령어를 통해 프로젝트의 상태를 체크할 수 있습니다. 이 경우 migrations 이 만들어지지 않고, 데이터베이스에도 영향을 주지 않습니다.
이제 migrate 명령어를 실행하고, 수정한 모델의 테이블이 데이터베이스에 만들어지도록 합니다.
$ python manage.py migrate
위 명령어를 입력하면 다음과 같은 내용을 볼 수 있습니다.
Operations to perform:
Apply all migrations: admin, auth, contenttypes, polls, sessions
Running migrations:
Rendering model states... DONE
Applying polls.0001_initial... OK
migrate명령어는 아직 적용되지 않은 모든 migrations에 작용합니다. (장고는 적용된 모든 migrations를 데이터베이스 안 django_migrations라고 불리는 특별한 테이블에 기록하고 있습니다.) 그리고 그 migrations들을 우리의 데이터베이스에 적용합니다. 우리가 모델에 만든 변경사항과 데이터베이스의 얼개(schema)를 동기화하는 것이지요.
migrations는 매우 강력하고, 프로젝트가 진행되는 동안 시간이 흐르며 모델이 변경되는 것을 가능하게 합니다. 데이터베이스나 테이블을 삭제, 또는 새로 만들지 않고도 말입니다. migrations는 데이터베이스가 데이터를 잃지 않고도 살아 있는 상태로 업그레이드 되는데 특화되어 있습니다. 우리는 이 부분에 대해 튜토리얼의 다른 부분에서 더 깊이 있게 다루게됩니다.
하지만 지금은 모델을 변경하는 세가지 과정에 대해서만 확실히 기억해둡시다.
모델을 수정한다. (models.py)
python manage.py makemigrations를 실행하여 변경사항에 대한 migrations를 만든다.
python manage.py migrate를 실행하여 변경사항을 데이터베이스에 적용한다.
2.4 Plying with the API
자, 이제 파이썬의 대화형 셸에서 달려볼 시간입니다. 그리고 무료 API를 가지고 놀아봅시다. 파이썬 셸을 호출하기 위해 아래 명령어를 사용합니다.
$ python manage.py shell
python 이라고만 입력하지 않는 이유는 manage.py가 DJANGO_SETTINGS_MODULE 환경에 변수로 저장되어 있기 때문입니다. (차후 내용 추가해야 함)
manage.py를 사용하고 싶지 않다면
manage.py를 사용하고 싶지 앟다면 DJANGO_SETTINGS_MODULE에서 환경 변수를 수정합니다. DJANGO_SETTINGS_MODULE은 mysite/settings.py 안에 있습니다. 일반 파이썬 셸을 불러낸 뒤 장고를 설치합니다.>>>import django >>>django.setup()AttributeError가 나타난다면 장고의 버전이 이 튜토리얼의 버전과 맞지 않는 것 같습니다. 이전 버전의 튜토리얼을 보거나, 새로운 버전의 장고를 설치합니다.
파이썬은 반드시 manage.py와 같은 폴더에서 실행해야 합니다. 또는 실행한 폴더가 파이썬의 패스에 속해야 합니다. 그래야 import mysite가 작동합니다.
manage.py를 사용하지 않는 방법을 마저 알고 싶다면 django-admin documentation을 참고하십시오. (생략)
파이썬 셸로 넘어온 다음, database API 문서를 탐험해보십시오.
# >>>는 프롬프트라고 불리며, 현재 파이썬 안에서 명령을 입력하고 있다는 것을 알려줍니다.
# 주석 번역 임시 생략
>>> from polls.models import Question, Choice # Import the model classes we just wrote.
# No questions are in the system yet.
>>> Question.objects.all()
<QuerySet []>
# Create a new Question.
# Support for time zones is enabled in the default settings file, so
# Django expects a datetime with tzinfo for pub_date. Use timezone.now()
# instead of datetime.datetime.now() and it will do the right thing.
>>> from django.utils import timezone
>>> q = Question(question_text="What's new?", pub_date=timezone.now())
# Save the object into the database. You have to call save() explicitly.
>>> q.save()
# Now it has an ID. Note that this might say "1L" instead of "1", depending
# on which database you're using. That's no biggie; it just means your
# database backend prefers to return integers as Python long integer
# objects.
>>> q.id
1
# Access model field values via Python attributes.
>>> q.question_text
"What's new?"
>>> q.pub_date
datetime.datetime(2012, 2, 26, 13, 0, 0, 775217, tzinfo=<UTC>)
# Change values by changing the attributes, then calling save().
>>> q.question_text = "What's up?"
>>> q.save()
# objects.all() displays all the questions in the database.
>>> Question.objects.all()
<QuerySet [<Question: Question object>]>
그런데 <Question: Question object>는 이 객체가 어떤 것인지 나타내는데 아무런 쓸모가 없습니다. polls/modes.py에서 Question 모델을 수정해서 알아보기 쉽도록 만들어 봅니다. Question 모델과 Choice 모델에 str() 메서드를 추가합니다.
# 작성위치 : polls/models.py
from django.db import models
from django.utils.encoding import python_2_unicode_compatile
@python_2_unicode_compatible #파이썬 2를 사용할 때만 필요합니다.
class Question(models.Model):
# 생략...
def __str__(self):
return self.question_text
@python_2_unicode_compatible #파이썬 2를 사용할 때만 필요합니다.
class Choice(models.Model):
# 생략 ...
def __str__(self):
return self.choice_text
__str__() 메서드를 모델에 추가하는 것은 중요합니다. 결과를 문자열로 나타내 주기 때문에 프롬프트와 관리자 모드를 사용하기 편해집니다.
__str__()은 미리 만들어져 있는 파이썬 메서드(normal Python methods)입니다. 우리는 모델에 우리가 직접 만든 메서드를 추가할 수도 있습니다.
# 작성위치 : polls/models.py
import datetime
from django.db import models
from django.utils import timezone
class Question(models.Model):
# ...
def was_published_recently(self):
return self.pub_date >= timezone.now() - datetime.timedelta(days=1)
위 예제는 기존에 만들어 두었던 Question이라는 클래스에 직접 만든 메서드를 추가하는 내용입니다.
우선 맨 첫줄의 import datetime과 세번째 줄의 from django.utils import timezone이 추가되었습니다. 첫번째 줄의 import datetime은 파이썬 기본 레퍼런스의 datetime모듈을, 세번째 줄은 장고의 시간관련 유틸리티를 이용할 수 있게 해줍니다.
그리고 Question 클래스의 함수부분에 was_published_recently라는 함수(메서드)를 추가하였습니다.
파이썬에서 시간관련된 부분을 다루는데 익숙하지 않다면 time zone support docs에서 관련 내용을 배울 수 있습니다.
이 바뀐 내용을 저장하고, 새로운 파이썬 대화형 셸을 엽니다. 명령어는 python manage.py shell 입니다.
# 해시'#'로 시작하는 내용은 모두 주석입니다.
# 조만간 이미지를 통해 정리된 내용으로 업데이트 하겠습니다. 구분이 어렵지만 일단은 이대로...
>>> from polls.models import Question, Choice
# polls 폴더에 저장한 모델들 중에서 Questions과 Choice를 불러옵니다.
# 모델에 __str__() 함수(=메서드)를 추가한 것이 제대로 동작하는지 확인해 봅시다.
>>> Question.objects.all()
<QuerySet [<Question: What's up?>]>
# 모델이 string으로 표현됩니다. (__str__()가 잘 작동합니다)
# 장고는 풍부한 데이터베이스 조회용 API를 제공합니다.
# 이 API는 전적으로 키워드 인수를 통해 동작합니다.
>>> Question.objects.filter(id=1)
<QuerySet [<Question: What's up?>]>
>>> Question.objects.filter(question_text__startswith='What')
<QuerySet [<Question: What's up?>]>
# 위는 filter를 사용해 데이터베이스를 조회하는 예시입니다.
# filter 뒤에 id 값을 입력할 수도 있고, question_test의 startswith 값을 사용할 수도 있습니다.
# 올해에 발행된 질문을 조회해 봅시다.
>>> from django.utils import timezone
>>> current_year = timezone.now().year
>>> Question.objects.get(pub_date__year=current_year)
<Question: What's up?>
# 장고의 유틸리티에서 timezone을 불러온 다음, current_year라는 변수에 timezone.now().year를 저장합니다.
# Question 안의 objects가 pub_date__year=current_year의 값을 가지는지 조회합니다.
# (pub_date는 우리가 앞쪽에서 미리 설정해 둔 값이며입니다.
# 그 뒤에 언더 바 두개를 추가하여, pub_date안쪽에서 검색할 값을 지정합니다.
# 여기서는 언더 바 두개 뒤에 year를 써서, pub_date 안쪽에서 year의 값을 찾고 싶다는 뜻입니다.
# 그리고 그것이 current_year와 일치하는지 확인합니다.
# 우리는 앞쪽에서 current_year에 timezone.now().year를 지정해 두었지요.)
# 존재하지 않는 아이디를 조회해달라고 요청해 봅시다. 요청한 아이디가 데이터베이스에 존재하지 않기 때문에 '예외'가 발생합니다. 그리고 오류 메시지가 나타납니다.
>>> Question.objects.get(id=2)
Traceback (most recent call last):
...
DoesNotExist: Question matching query does not exist.
# 데이터베이스를 조회하는 방식 중 primary key (주로 pk라고 줄여서 부릅니다.)를 이용하는 것이 가장 흔하게 사용됩니다.
# 그렇기 때문에 장고는 데이터베이스 조회에 사용되는 primary key를 위한 shortcut을 제공합니다.
# 다음 문장은 Question.objects.get(id=1)와 동일한 역할을 합니다. id대신 pk를 사용했지만 그대로 작동하지요.
>>> Question.objects.get(pk=1)
<Question: What's up?>
# 우리가 직접 만든 custom method가 잘 작동하는지 확인해봅시다.
>>> q = Question.objects.get(pk=1)
>>> q.was_published_recently()
True
# Give the Question a couple of Choices. The create call constructs a new
# Choice object, does the INSERT statement, adds the choice to the set
# of available choices and returns the new Choice object. Django creates
# a set to hold the "other side" of a ForeignKey relation
# (e.g. a question's choice) which can be accessed via the API.
>>> q = Question.objects.get(pk=1)
# Display any choices from the related object set -- none so far.
>>> q.choice_set.all()
<QuerySet []>
# 세 개의 choice를 만들어 봅시다. 마지막 choice는 q가 아닌 c 라는 점 주의하세요.
>>> q.choice_set.create(choice_text='Not much', votes=0)
<Choice: Not much>
>>> q.choice_set.create(choice_text='The sky', votes=0)
<Choice: The sky>
>>> c = q.choice_set.create(choice_text='Just hacking again', votes=0)
# 주의! 바로 윗줄은 q.choice_set.create가 아닙니다. c = q.choice_set.create 입니다!
# Choice 개체들은 그들과 연결된 Question 개체의 API access를 가지고 있습니다.
>>> c.question
<Question: What's up?>
# 또한 Question 개체들은 Choice개체들에 접근할 수 있습니다.
>>> q.choice_set.all()
<QuerySet [<Choice: Not much>, <Choice: The sky>, <Choice: Just hacking again>]>
>>> q.choice_set.count()
3
# The API automatically follows relationships as far as you need.
# 관계를 분리하기 위해 두개의 언더바를 사용합니다.
# 이것은 당신이 원하는 만큼 얼마든지 중첩해서 쓸 수 있고, 제한도 없습니다.
# Find all Choices for any question whose pub_date is in this year
# (reusing the 'current_year' variable we created above).
>>> Choice.objects.filter(question__pub_date__year=current_year)
<QuerySet [<Choice: Not much>, <Choice: The sky>, <Choice: Just hacking again>]>
# Let's delete one of the choices. Use delete() for that.
>>> c = q.choice_set.filter(choice_text__startswith='Just hacking')
>>> c.delete()
(내용 부분적 생략.차후 보강할 것)
2.5 Introducing the Django Admin
Philosophy
스태프나 고객(client)이 관리자 사이트에서 사이트의 내용을 수정하고, 추가하고, 삭제할 수 있도록 만드는 것은 아주 지루한 일입니다. 창의성도 필요 없고요. 이런 이유 때문에, 장고는 모델에 대한 관리자 인터페이스가 완전히 자동으로 만들어지도록 했습니다(!)
장고는 뉴스룸과 같은 환경에서 만들어졌습니다... 이하 생략
Creating an admin user
먼저 우리는 관리자 사이트에 로그인 할 수 잇는 사용자를 만들어야 합니다. 터미널에 아래의 명령어를 입력하세요.
$ python manage.py createsuperuser
Start the development server
$ python manage.py runserver
원하는 username을 입력하고 엔터를 누릅니다.
Username: admin
그러면 이메일을 입력하라는 문구가 나올 겁니다.
Email address: [email protected]
그리고 마지막으로 비밀번호를 설정합니다. 설정한 비밀번호를 확인하는 과정이 한 번 더 있습니다.
Password: **********
Password (again): *********
Superuser created successfully.
*터미널에서 입력하는 비밀번호는 원래 화면에 나타나지 않습니다. 당황하지 마세요.
Enter the admin site
장고의 관리자 사이트가 기본설정을 기반으로 만들어졌습니다. 개발자용 서버를 작동시키고 탐험해 보겠습니다.
만약 서버가 작동하지 않는다면 서버를 껐다 켜세요. 서버를 켜는 명령어는 다음과 같습니다.
python manage.py runserver
서버가 제대로 작동하면, 웹 브라우저를 열고 로컬 도메인의 뒤에 /admin/을 붙여넣습니다. 예를 들어 이런 식입니다. http://127.0.0.1:8000/admin/
그러면 관리자 로그인 창이 나타납니다.
(기타 내용 생략 )
Enter the admin site
터미널에서 설정한 superuse의 계정으로 로그인 합니다. 그러면 장고 관리자 사이트의 첫 페이지가 나타납니다.
페이지에는 우리가 수정할 수 있는 몇가지 내용이 있습니다. group과 users입니다. 이 내용은 django.contrib.auth에서 제공되는 것입니다. 이 인증 프레임워크는 장고에 포함되어 있습니다.
Make the poll app modifiable in the admin
하지만 우리의 poll앱은 보이지 않네요. 아직 관리자 사이트의 첫 페이지에 나타나지 않았습니다.
딱 한가지만 하면 poll 앱이 여기에 나타나게 됩니다. 우리는 Question 개체가 관리용 인터페이스를 가진다고 admin 파일에 알려줘야 합니다. polls/admin.py에 아래 내용을 작성해주세요.
# 작성위치 : polls/admin.py
from django.contrib import admin
from .models import Question
admin.site.register(Question)
Explore the free admin functionality
이제 관리자 사이트의 첫 페이지에 Question이 나타날겁니다. Qustions를 누르면 change list페이지가 나타납니다. 이 페이지는 데이터베이스에 있는 모든 question을 보여주고, 우리가 그 중 하나를 선택해 수정할 수 있게 해줍니다. 우리가 초반에 만든 "What's up?" 질문이 보이네요.
"What's up?"을 누르면 그 질문을 수정할 수 있습니다.
아래 내용에 주의하세요.
- 이 양식은 Question모델에 의해 자동으로 생성된 것입니다.
- 다양한 모델 필드의 타입들(DateTimeField, CharField)은 적절한 HTML 입력값(input) 위젯에 응답합니다. 필드 각각의 타입은 스스로를 장고 관리자 사이트에서 어떻게 나타내야 할 지 알고 있습니다.
- 각각의 DateTimeField는 자바 스크립트 단축키를 가져옵니다. Dates는 'Today'의 단축키를 받고 calander를 팝업시킵니다(?). times는 'Now'의 단축키를 받고 일반적으로 입력되는 시간들의 편리한 목록을 팝업합니다(?)
아래 내용을 보시면 몇가지 옵션이 있습니다.
- Save : Save는
- 이하 내용 생략