Django : Model

오늘은 드디어 모델을 만들어 볼것이다. 이는 실질적으로 DB를 관리할 수 있는 첫 걸음이다. 지금 이해해야 나중에 form을 다루면서 외우는 식이 아닌 이해하는 식으로 django를 풀어나갈 수 있다. 진짜 머리아픈 부분의 시작이니 잘 따라가보자

---

Model

: DB의 테이블을 정의하고 데이터를 조작할 수 있는 기능들을 제공 (DB를 직접 다루는 것은 SQLite로 진행 예정)

=> 어떤 데이터를 저장할지 테이블 구조를 설계하는 '청사진(Blueprint)' 다. 게시글을 예로들면 제목과 내용을 데이터로 저장하려면 title과 content를 작성한다고 가정하자.

model 설정값(아래서 배울 Migrations을 진행하면 확인 가능)

 

먼저 class 선언을 하여 내가 사용할 model을 정의한다

. 모델명 - 모델에 들어갈 필드(데이터 테이블)명 - 해당하는 데이터 타입 - 데이터타입 별 제약 조건 순으로 작성한다. 

• 클래스 변수명

: 데이터 테이블의 각 "필드 명"

: 변수명은 파스칼 케이스(=Pascal Case, 모든 단어의 첫 글자를 대문자로 시작)를 따른다

 

• 데이터 타입

: 데이터 테이블에 채워질 데이터들의 타입

: 다양한 필드가 있으며 django의 models에서 제공하는 기본 Field를 사용한다

models.Field에 접근하면 있는 목록들

• CharField : max_length 매개변수를 사용하여 문자열 최대 길이 지정
• TextField : 긴 문자열 필드
• InterField : 정수 필드
• FloatField : 부동 소수점 수 필드
• DecimalField : 고정 소수점 수 필드
• BooleanField : 참(True) or 거짓(False) 값을 갖는 필드
• DateField : 직접 설정하는 날짜 필드
• DateTimeField : 날짜와 시간을 나타내는 필드(Auto_now / Auto_now_add)
• ImageField : 이미지 파일을 받는 필드
• ...

위의 필드를 주로 사용하게 될 것이다.

 

• 제약 조건 (model Field 클래스의 키워드 인자로 필드 옵션에 해당)

: 데이터가 올바르게 저장되고 관리되도록 하기 위한 규칙

: ex) 숫자만 저장(validators=[RegexValidator(r'^[0-9]+$')]), 문자 최대 길이(max_length) 등 설정 가능

 

Article
id	title	content
...	...	...
...	...	...

 

Model의 형태를 쉽게 보면 위처럼 데이터 표가 작성되었다. 

 

Migrations

 

: model 클래스의 변경사항(필드 생성, 수정 삭제 등)을 DB에 최종 반영 하는 방법으로 앞서 model을 작성했을텐데, 해당하는 설계도 파일(초안)을 확정짓는 과정이다.

• makemigrations : model class를 기반으로 최종 설계도(migration) 작성

왼쪽은 makemigrations 명령어, 오른쪽은 실행시 터미널에서 migrations 설계도면이 등록된 것을 확인

추가로 db.sqlite3 파일이 생긴 것을 확인할 수 있다

 

최종 설계도를 저장은 했지만, 아직 DB로 넘겨서 옷을 입혀주진 않았기 떄문에 Tables가 비어있는 것을 확인 할 수 있다.

 

• migrate  : 최종 설계도를 DB에 전달하여 반영

최종 설계도가 db에 적용되는 모습이다.

DB에도 적용된 모습을 확인할 수 있다

 

app 파일 내부에 migrations라는 폴더가 있던 것을 보았을 텐데, 이제 해당 폴더로 들어가보면 initial.py로 최초 모델이 등록된 모습을 확인할 수 있다.

 

최종 설계도로 DB를 만들었다고 했는데, 그러면 수정을 한 순 없을까? 두가지 방법이 있다. 하나는 데이터 베이스와 설계도를 삭제하고 다시 migration 해주는 것. 이럴경우 기존에 저장된 DB 데이터가 날아가게되어 초창기에 하는 것이 아니라면 권장되지 않는다.

데이터 만드는 법은 나중에 배우는데 비교를 위해 임의로 생성해두었다

 

다른 방법은 추가 모델 필드를 작성하고 migration을 덮어씌워주는 것. 하지만 이전에 저장된 DB 데이터는 모델 필드가 추가되면 작성되지 않은 상태다. 문제가 생기지 않을까?

일단 진행해보자.

 

게시글 작성 시간과 수정 시간을 넣어주었고 제약조건을 설정해주었다

 

auto_now_add : 데이터 최초 생성시 기록되는 데이터

auto_now : 데이터 생성 및 수정시 새롭게 갱신되는 데이터

 

그냥 여기서 migration을 던져주고 싶지만 컴퓨터는 매정했다. 

이미 기존 테이블이 존재하기 때문에 필드를 추가할 때 기본 값 설정을 요청 터미널을 반환해준다

 

1) 현재 대화를 유지하면서 직접 기본 값을 입력 하는 방법

2) 현재 대화에서 나간 후 models.py에 기본 값 관련 설정을 하는 방법

 

그렇다면 1번을 선택해보자

django가 제안하는 값으로 쓸것이냐 혹은 값을 제공해줄건지 물어본다

 

1-2) 아무것도 입력하지 않고 enter를 누르면 Django가 제안하는 기본 값으로 설정

-> 우리의 경우 추가하는 필드의 기본값은 날짜 데이터이기 때문에 직접 입력하는 것보다 Django가 제안하는 기본 값을 사용하는 것이 좋다.. default: timezone.now를 보아하니 현재 시각으로 설정해주는 것 같다. 엔터!!!

당연히 설계도만 저장했으니 바뀐게 없다. migrate 까지 해주자.

이후 데이터 베이스를 확인해보면 두개의 필드가 추가로 작성되었고, 기본값이 할당되어있는 것을 확인할 수 있다

두번째 설계도도 등록된 것을 확인할 수 있다. created_at에 기본값이 자동으로 할당된 기록도 볼 수 있다.

 

근데 왜 migration 폴더에서 initial 파일에 덮어씌워진 것이 아니라 새롭게 생성될까? 이는 Django가 설계도를 쌓아가면서 추후 문제가 생겼을 때, 복구가 가능하게 만들어 놓은 안전장치이다. (git commit과 유사)

 

변경사항 (model class 변경)
↓
새로운 설계도 생성 (makemigrations)
↓
DB 반영 (migrate)

그리고 이제 python manage.py runserver 를 진행하면 계속 봐왔던 빨간색 글씨의 오류를 더이상 안 볼 수 있다.

---

 

Admin site

Automatic admin interface

 

: Django 는 추가 설치 및 설정 없이 자동으로 관리자 인터페이스를 제공한다

위에서 데이터 3개를 만들어 두었던 것을 보았을텐데, 이는 관리자 계정을 통해 model에 직접 데이터를 넣어준 것이다. 아직 데이터를 저장하는 것을 배우지 않았기 때문에 해당 방법을 사용할 수 있다. 즉, 데이터 확인 및 테스트 등을 진행하는데 매우 유용하다

 

1. admin 계정 생성

: email은 선택 사항이므로 입력하지 않아도 생성이 가능하다

: 비밀번호는 입력해도 터미널에 출력되지 않으니 입력이 되지않는다고 생각하지 말고 입력하면 된다

슈퍼 계정 생성 명령어

빨간색 글씨는 비밀번호에 대한 경고라서 무시해도 된다

admin 계정이 생성이 완료된 화면

관리자 접속 URL

아까 만들었던 계정으로 로그인하면 관리자 홈페이지를 이용할 수 있다

 

하지만 우리가 등록했던 article 모델의 데이터는 아직 확인할 수 없다. 그 이유는 admin과 app이 연결이 되어있지 않기 때문인데, app 폴더 내부에 admin.py를 수정해주면 접근이 가능하다.

Article 모델을 연결해주고 등록해준다

Articles app에 모델 클래스가 등록된 것을 확인할 수 있고, 작성했던 model의 데이터를 직접 추가 및 삭제가 가능하다

생성시 DB에도 실시간 적용되는 것을 확인할 수 있다

---

부록

 

데이터 베이스 초기화

 

앞서 잠깐 등장했던 migration을 다시 해주면서 삭제해주는 방법이 있다고 설명했는데, 엄청 간단하다. 만들어져있는 DB파일과 설계도를 날려주면 된다.

설계도 + DB 삭제

 

이외 파일을 건드리면 버그가 날 수 있으니 조심한다!

 

Migrations 명령어

 

: python manage.py showmigrations

 - > migrations 파일들이 migrate 됐는지 안됐는지 여부를 확인하는 명령어

[X] 표시가 있으면 migrate가 완료되어있는 것

 

: python manage.py sqlmigrate appname number

migrations 파일이 SQL 언어(DB에서 사용되는 언어)로 어떻게 번역되어 DB에 전달되는지 확인

---

이제 데이터를 직접 보고 출력할 수 있으니 앞서 지루했던 시간보다 재미있는 파트가 계속 나올 예정이다. 기능을 구현하는데 집중하게 될 것이기 때문에 어렵지만, 배워가는 느낌을 확 받을 수 있다. 많이 왔으니 온 만큼만 더 가자.