Django 튜토리얼 파트2
-
DB 설치
-
setting.py
Django 설정을 모듈 변수로 표현한 보통의 Python 모듈
기본적으로 SQLlite 사용하도록 구성됐으며 입문용에 적합 실제 프로젝트에서는 DB 교체하느라 골치 아파질 일을 피하기 위해 확장성있는 DB 사용하는 것이 좋음
다른 DB 적용 시 여러 세팅 필요
-
-
INSTALLED_APP
현재 Django 인스턴스에서 활성화된 모든 Django 어플리케이션들의 이름 담김
-
migration
models.py에 정의된 모델의 생성/변경 내역을 히스토리 관리, DB에 적용 등과 같은 기능을 제공하여 손쉽게 DB구조에 적용하는 일련의 과정
장고가 기본적으로 제공하는 ORM 서비스를 통해 진행됨
모델의 변경 내역을 DB Schema(DB 데이터 구조)로 반영시키는 효율적인 방법 제공
초기 setting.py의 migration 파일(INSTALLED_APP) 반영해주는 역할도 함
DB schema 버전 컨트롤 시스템
모델의 반복적인 변경 작업과 동작 중인 DB 자료 손실 없이 업그레이드 하는 데 최적화 됨
-
migrate 명령어
-
migrate
적용되지 않은/변경된 migrations 들의 파일을
DB에 적용해서 변경사항들과 DB의 schema 동기화 이루어냄
-
makemigrations
models에 적용한 변화를 기반으로 새로운 migrations 만들어냄
-
sqlmigrate
migration 이름을 인수로 받아 실행하는 SQL 문장을 보여줌
-
-
-
모델 만들기
-
모델
부가적인 메타데이터를 가진 DB의 구조
데이터에 관한 단 하나의 가장 확실한 진리의 원천 저자하는 데이터의 필수적인 필드들과 동작들을 포함
모델에 대한 코드는 DJango에게 상당한 양의 정보 전달
-
모델로 Django 가 할 수 있는 일
-
이 앱을 위한 DB 스키마 생성
-
모델 객체에 접근하기 위한 Python DB 접근 API 생성
-
DRY 원칙 따르며 원칙에 따라 데이터 모델을 한곳에서 정의하고 이것으로 부터 자동으로 뭔가를 유도하는 것이 목표
-
DRY 원칙
고유한 개념 및 데이터는 단 한 번, 단 한 곳에 존재하는 것이 원칙.
중복성은 나쁜 것이고 정규화는 좋은 것
각 모델은 클래스의 서브 클래스로 표현되며 DB filed를 표현함
-
DB field
Field 클래스의 인스턴스로써 표현
각 필드가 어떤 자료형을 가질 수 있는지 Django 에게 말해줌
각 Field 인스턴스의 이름은 기계가 읽기 좋은 형식의 DB필드 이름이며 DB에서는 컬럼명으로 사용
외래 키 필드명에 “id”이름 자동으로 추가됨
-
인수
-
첫번째 위치 인수
사람이 읽기 좋은 이름 지정 가능
DJango 의 내부를 설명하는 용도로 종종 사용
사용하지 않을 시 Django는 기계가 읽기 좋은 형식의 이름 사용
-
필수 인수
몇몇 Field클래스들이 필요로 함
-
선택 인수
선택적으로 옵션 적용
-
-
-
메서드
해당 모델에 메서드 추가해서 기능 추가 가능
-
-
-
모델의 활성화
앱을 프로젝트에 포함시키기 위해서는 앱 구성 클래스에 대한 참조를 INSTALLED_APPS 설정에 추가해야 함
-
순서
-
모델 변경
-
makemigrations 로 모델 변경시킨 사실과 변경 사실 migration으로 저장시키고 싶다는 것을 DJango 에게 알려줌
-
migrate 명령어로 모델에서의 변경사항들과 DB의 schema 동기화
-
-
-
API 가지고 놀기
Python 쉘에서 DJango API 자유롭게 가지고 놀 수 있음
모델의 관계, API에서 이중 밑줄(__) 등의 API 존재
-
DJango 관리자 소개
사이트 관리자가 컨텐츠를 편집할 수 있는 통합적인 인터페이스를 생성하는 문제를 해결해줌
기본적으로 활성화 됨
추가된 앱은 admin.py 에서 적용
-
서식
모델에서 자동 생성
각 필드 유형들은 적절한 HTML 입력 위젯으로 표현
-
순서
-
관리자 아이디 생성
-
admin.py 수정
-
관리자 페이지 접속 및 수정
-
-