[Django] 튜토리얼 part 2 (1) - 모델, 데이터베이스

첫 번째 장고 앱 작성하기, part 2  를 따라해본 것을 기록! (튜토리얼은 감동적으로 한국어를 지원합니다.)

이 장에서는 데이터베이스를 설치하고 첫 모델을 생성한 후, Django에서 자동 생성되는 관리자 사이트에 대해 짧게 소개한다고 합니다.

이 포스팅에서는 관리자 사이트까지 안다루고 다음 포스팅에서 다루도록 할게요!!

 

Database

mysite > settings.py에 가보면 
이렇게 기본 데이터베이스 설정이 되어있습니다.

 

 

기본적으로는 SQLite을 사용하도록 구성되어 있습니다.

BASE_DIR은 mysite이고 그 안에 있는 db.sqlite3 파일을 보고 있네요

 

 

다른 DB로 바꿀 수 도 있다고 합니다! 문서를 참고해주세요 :-) 

 

장고에서는 DB에 대한 ORM(Object-Relatinal Mapping)을 지원해준다고 합니다.

ORM은 Object에 대한 정의를 바탕으로 DB에 매핑해주는 방식입니다.

그래서 우리는 모델을 만들기만 하면 Database 작업은 장고가 알아서 해준다고 합니다. (아래에서 더 설명할게요)

우선 모델에 대해 자세하게 알아보겠습니다. 

Model

장고에서 모델에 대한 정의는 다음과 같습니다.

튜토리얼에는 

"모델이란 부가적인 메타데이터를 가진 데이터베이스의 구조(layout)를 말합니다." 라고 나와있습니다.

 

공식 문서에는 아래와  같이 나와있습니다.

 

 

"모델은 field들과 너가 저장하는 데이터에 대한 행동(?)을 가지고  있다. 각각의 모델은 데이터 베이스 테이블로 맵핑된다" 

이 부분을 주목해주세요

 

예제를 보겠습니다. 

Person이라는 모델이 있습니다. (models.Model) 이라고 해주는 것은  django.db.models.Model 의 subclass 이라는 뜻입니다. 

이 모델은 first_name과 last_name이라는 필드를 가지고 있습니다.
각 필드의 타입은 Char이고 최고 길이는 30이라는 제약조건을 가지고 있네요 :-) 

 

모델은 테이블에, 필드는 칼럼에 매핑됩니다.  

장고는 위에서 정의한 Person모델을 보고 아래와 같은 방식으로 테이블을 만듭니다. 

하나씩 살펴볼게요...!! 

 

1. myapp_person 이라는 테이블 이름 

장고에서는 모델 클래스 이름과 그 모델을 포함하고 있는 앱의 이름으로 자동으로 데이터 베이스 테이블의 이름을 지어줍니다. 

그래서 myapp_person이라는 테이블 이름을 만들어줬습니다. 테이블 네임은 overridden될 수 없다고 하네요 (테이블 이름을 커스텀하게 바꿀 수 없다는 뜻인듯)

 

2. primary key인 id라는 칼럼

 

장고에서는 primary key도 자동으로 만들어준다고 합니다. 모델에 아래와 같은 방식으로 id 필드를 만들어준다고 합니다.

 

이 id는 auto-incrementing primary key 입니다. 

 

근데 장고가 이렇게 만들어 주는 것은 모델에 primary key를 지정해주지 않았을 때입니다. 

만약 모델을 정의할때 custom primary key를 정의해주면 ( 그 방법은 해당 필드에 primary_key=True 를 명시하면 됨 )

장고는 Field.primary_key가 명시적으로 설정되어있는 것을 보고 자동으로 id 칼럼을 만들어주지 않습니다...!!! 

그래서 id 필드는 overridden가능하다 라고 문서에 나와있는 것 같습니다.

 

 

primary key를 정의해준 모델의 예 입니다.

 

3. first_name , last_name 칼럼

 

우리가 모델 안에 정의한 필드를 칼럼으로 매핑해주고 있는 것을 볼 수 있습니다.  

 

 

 

---

 

칼럼이 필드랑 같은 말이 맞는 지 구글링 하다가 좋은 자료를 발견해서 공유합니다 :-) 

http://www.sqler.com/476174

 

---

 

 

그럼 이제 다시 튜토리얼로 돌아와서 Polls앱에 필요한 Question모델과 Choice모델을 만들어보겠습니다.

polls/models.py에서 모델을 정의해주세요

 

 

Question 모델

Question모델은 question_text라는 필드를 가지고 있습니다. (타입은 char, 제약조건은 길이 200까지)

pub_date라는 필드도 가지고 있습니다. (타입은 datetime) 

그리고 pub_date 필드는 verbose_name으로 'date published' 를 넘겨주고 있네요 

 

verbose_name이란 무엇일까요..?! 

 

verbose_name은 human-readable한(사람이 읽기 좋은) 필드 네임이라고 합니다. 

verbose_name을 안 넘겨주면 장고는 클래스안에 정의한 field의 이름과 똑같이
verbose_name을 만들어준다고 하네요. (만약에 verbose_name을 지정 안해줬으면 pub_date가 verbose_name이 되는 것입니다)

장고에서는 클래스 안에 정의한 필드네임은 기계가 읽기 좋은 형식(machine-friendly format)의 데이터베이스 필드 이름이라고 말합니다.

pub_date말고 그 외의 다른 필드들은, 기계가 읽기 좋은 형태의 이름이라도 사람이 읽기에는 충분하기 때문에 

pub_date 에 한해서만 인간이 읽기 좋은 형태의 이름을 정의하겠습니다. 

 

 

Choice 모델

 

question이라는 필드를 가집니다. foreign key로 Question의 primary key를 참조합니다.

foreign key를 통해  "각각의 Choice 가 하나의 Question 에 관계된다" 라는 관계 설정을 해주었습니다. 

 

그리고 foreign key의 on_delete를 설정해주었는데요, 

 

 

 

CASCADE 뜻은 '종속' 인데,  Choice가 참조하고 있는 Question이 삭제되면 Choice도 삭제 되도록 해주는 것 같습니다.

(질문이 지워지면 해당 질문에 달려있는 Choice들도 당연히 삭제 되어야겠죠?+?) 

 

 

그리고 choice text라는 필드를 가집니다. (타입은 char, 제약조건은 길이 200까지)

마지막으로 votes라는 필드를 가집니다. (타입은 int, 기본값은 0)

 

 

모델 정의가 끝났습니다! 그러면 이제 장고한테 모델이 추가된 것을 알려줘야합니다...!! 

 

Django에게 모델 변경사항을 알려주기

 

1) polls 앱을 현재의 프로젝트에 포함시키기

 

우선 polls앱을 mysite라는 현재의 프로젝트에 포함시켜야합니다.

앱을 현재의 프로젝트에 포함시키기 위해서는, 앱의 configuration에 대한 참조를 INSTALLED_APPS 설정에 추가해야합니다 

 

polls > apps.py 에 가보면 AppConfig 클래스를 상속받고 있는 PollsConfig라는 클래스가 있습니다.

이 클래스를 mysite의 INSTALLED_APPS 에 추가해줄것입니다!

 

 

 

현재 mysite > settings.py에 가보면 INSTALLED_APPS 에 장고를 처음 시작할때 장고가 기본으로 만들어주는 앱들이 적혀있는 것을 볼 수 있습니다. 

 

 

여기에 polls.apps.PollsConfig 를 추가해주세요 

 

 

2) 변경사항에 대한 마이그레이션을 만들기

 

makemigrations 을 실행시킴으로서, 당신이 모델을 변경시킨 사실과(이 경우에는 새로운 모델을 만들었습니다)
이 변경사항을 migration으로 저장시키고 싶다는 것을 Django에게 알려줍니다

 

아래 명령어를 실행시켜주세요

python manage.py makemigrations polls

 

그러면 아래에 

polls/migrations/0001_initial.py 에 

Question모델과 Choice모델을 만든 것을 저장했어~ 라고 알려줍니다. 

 

0001_initial.py이라는 파일이 생겼고 

 

 

 

저 파일에 들어가보면 모델을 만든 것이 기록되어있는 듯 합니다. 

 

 

그리고 migration이 내부적으로 어떤 SQL 문장을 실행하는지 살펴볼수도 있습니다!!!

sqlmigrate 명령은 migration이름을 인수로 받아, 실행하는 SQL 문장을 보여줍니다.

 

migration이름은 0001이니까 이걸로 아래의 명령어를 실행시켜주세요

python manage.py sqlmigrate polls 0001

 

오 내부적으로 어떤 SQL 문장을 실행하는 지 나오네요 👍👍

 

 

 

3) 변경사항을 데이터베이스에 적용시키기 

 

위에서 만들어준 변경사항을 데이터베이스에 반영시켜야합니다.

아래 명령어를 입력해주세요 

 

 

변경사항이 적용되었다는 내용이 출력되네요 

 

 

 

변경사항을 알아서 적용안시켜주고 따로 명령을 내리도록 하는 이유는 아래와 같습니다

 

마이그레이션을 만드는 명령과 (2번에서 했던 것)

데이터베이스에 적용하는 명령이 분리된 것은 (3번에서 했던 것)

버전 관리 시스템에 마이그레이션을 커밋하고 앱과 함께 출시할 수 있도록 하기 위해서 라고 합니다.

이는 당신의 개발을 쉽게 해줄 뿐 아니라, 다른 개발자가 프로덕션에서 사용할 수 있게 해준다고 합니다.

 

 

 

 

앞으로 모델에 변경사항이 있을 때마다 이 세가지를 꼭 기억해주세요!!!! 

 

 

 

Python Shell에서 모델 다뤄보기 

 

위에서 만든 모델들을 Python Shell에서 가지고 놀아보겠습니다 :-) 
아래의 명령어로 Python Shell을 실행시켜주세요 

 

 python manage.py shell

 

그리고 우리가 방금정의했던 모델들을 import 시켜줍니다

 

from polls.models import Choice, Question

 

 

그 다음 아래에 있는 것들을 테스트해보세요~ 

 

여기서 하나 주의깊게 볼 것은 

Question을 하나 만들고 그 Question의 choice_set 이라는 것을 출력해보세요! 

>>> q = Question.objects.get(pk=1)
>>> q.choice_set.all()

 

출력해보면 이렇게 나옵니다. 

<QuerySet []>

 

오잉 모델을 보면  choice_set이라는 것이 없는 데 어떻게 나오는 건지 신기합니당!!! 

 

 

 

그 이유는 Choice모델이 Question을 ForeignKey로 참조하고 있기 때문에

장고에서 각 Question에게 자신을 외래키로 참조하고 있는 Choice모델의 모음을 출력할 수 있는 필드를 자동으로 추가해주는 것입니다..!! 

default로 만들어주는 필드이름은 choice_set 같이 "모델이름_set" 인데 이것을 바꿀 수도 있습니다. 

 

이런 식으로 relate_name을 지정해주면 된다고 합니다. 

https://stackoverflow.com/questions/31746571/what-is-choice-set-all-in-django-tutorial

 

 

자세한 것은 relations 문서 를 봐주세요..!! 

 

 

그리고 Question에 choice도 추가 해보세요!

 

 

 

 

 

 

GUI 환경(관리자 사이트)에서 추가한 데이터베이스를 보는 법은 다음 글에서.... 💨🍃