튜토리얼 이어서

• 1장을 보고 2장을 이어가길 바란다. 공식 문서 튜토리얼에 내 입맛과 부족한 정보를 담아서 정리하는 것에 가깝다.

Django에서 DB를 다루는 방법. mysite/settings.py 에서 기본적으로 sqlite. SQLite는 Python에서 기본으로 제공되기 때문에 별도로 설치할 필요가 없다. 그러나 실제 프로젝트를 시작할 때에는, 나중에 데이터베이스를 교체하느라 골치 아파질 일을 피하기 위해서라도 PostgreSQL 같이 좀 더 확장성 있는 데이터베이스를 사용하는 것이 좋다.

django Ddatabase

• 버전 체크 존나 민감한 부분이다. 여기서는 django 3.x 이상 (python 3.7) / mysql 8.x 이상이라는 점 유의하고 보자.. 버전에 따라 어떤 커넥터, 모듈, 설정 방법이 상이하다. 사실 이게 제일 빡치는 부분. 도커를 찬양

공식 지원 DB

• Django는 다양한 데이터베이스 서버를 지원하며 PostgreSQL , MariaDB , MySQL , Oracle 및 SQLite에서 공식적으로 지원된다. 소규모 프로젝트를 개발 중이거나 프로덕션 환경에 배포할 계획이 없는 경우 SQLite는 일반적으로 별도의 서버를 실행할 필요가 없기 때문에 최상의 옵션이다.

• PostgreSQL을 사용하는 경우 psycopg2 패키지가 필요합니다. 자세한 내용은 PostgreSQL 참고 사항을 참조.

• MySQL 또는 MariaDB를 사용하는 경우 mysqlclient와 같은 DB API 드라이버가 필요하다. 자세한 내용은 MySQL 백엔드에 대한 참고.

• Oracle을 사용하는 경우의 cx_Oracle이 필요하다. 오라클 백엔드에 대해 지원되는 버전에 대한 자세한 내용.

Mysql

• mysite/settings.py 파일에서 하단 부분을 보면 DB 설정이 아래와 같이 되어있는 것을 알 수 있다. sqlite에서 mysql로 바꿔보자.

# Database
# https://docs.djangoproject.com/en/3.2/ref/settings/#databases

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': BASE_DIR / 'db.sqlite3',
    }
}

• default 값을 해당 키값으로 변경해준다. ENGINE – 'django.db.backends.sqlite3', 'django.db.backends.postgresql', 'django.db.backends.mysql', 또는 'django.db.backends.oracle'.

• SQLite 를 데이터베이스로 사용하지 않는 경우, USER, PASSWORD, HOST 같은 추가 설정이 반드시 필요합니다. 또한 사용할 Database를 만들어야 한다! -> mysql 설치가 필요하고, 해당 mysql cli (대화형 프롬프트)를 통해 CREATE DATABASE database_name; 가 필요하다.

• mysql을 사용하기 위해서는 DB Connector를 설치해야 한다. python server <-> mysql server 와 통신을 할 수 있어야 하기 때문이다. pymsql 또는 mysqlclient를 사용하면 되는데, 공식 문서에서는 후자를 권장한다. pip install mysqlclient

• 이제 'DB USER'에 대한 개념이 필요하다. 물론 root로 무지성으로 진행해도 되나, 우리는 '실제 사용'에 초점을 맞춰서 진행할 것이기 때문에, 유저를 만들고, 해당 유저에 대해 '특정 ip 접근 권한, 그리고 해당 유저의 권한' 설정을 해줘야 한다.

  • mysql 5.x 버전 유저 관리

# version 8.x 기준으로 내가 직접한 DB 설정 과정이다. 설치 - 실행 - 기본설정은 생략
# root 계정에서 시작
create user django@'%' identified by 'django'; # @뒤에는 접근가능한 ip 정보다. -> %는 전역 접근 가능 설정
CREATE DATABASE django;
grant all privileges on django.* to django@'%' with grant option;
flush privileges;

# mysql database로 들어가서 잘 생성되었는지, 권한은 어떤지 체크
use mysql
select * from user\G; # \G 옵션으로 세로행으로 보기 좋게 가능, 또는 pager less -SFX사용

• python(Django) 서버에 DB connection을 하려면 해당 유저의 정보가 필요하다. 해당 정보를 우린 실제로는 '환경 변수' 등으로 외부 노출을 하지 않은채 배포를 한다. 해당 부분을 임의로 프로젝트 최상위 경로에 db_config.py라는 파일을 만들어서 대체한다.
  • 어떻게 환경 변수로 노출하지 않고 배포를 하냐? 에 대한 답은 무수히 많다. 방법은 알았으니 결론은 본인이 내리면 된다.
  • macOS의 venv 가상 환경에서 mysqlclient 설치 에러시 확인

# DB 정보를 python dict 정보로 저장하고 사용하기. 
# db config information
DATABASE = {
    'default' : {
        'ENGINE': 'django.db.backends.mysql',
        'NAME': 'django',
        'USER': 'django',
        'PASSWORD': 'django',
        'HOST': 'localhost',    # or 127.0.0.1 / 또는 실제 DB 호스팅중인 서버 ip
        'PORT': '3306'          # 이건 자율이지만 규칙이다.
    }
}

• mysite/settings.py에 import db_config를 추가해주자. 그리고 DATABASE dict에 접근해서 해당 정보를 채워주면 된다.
  DATABASES = db_config.DATABASE

• 그리고 하단에 언어, 시간 설정값을 바꿔줘야 한다. USE_TZ True/False 변수설정 차이는

  • True : 장고 개발시 datetime 객체를 사용한다.
    import datetime
    now = datetime.datetime.now()

  • False : 장고 개발시 time-zone-aware datetime 객체를 사용
    from django.utils
    import timezone now = timezone.now()

LANGUAGE_CODE = 'ko-kr'     # 언어 - 국가 설정
TIME_ZONE = 'Asia/Seoul'    # 시간대 
USE_I18N = True             # 국제화 -> Internationalization
USE_L10N = True             # 지역화 -> localization
USE_TZ = True               # 장고 시간대 

드디어 다 되었다

• python manage.py migrate 로 django admin에 필요한 table을 마이그레이션 진행해 주자. 사실 이 마이그레이션 부분 만으로 django ORM system에 반할만 하다!!

• 본인은 macOS venv환경의 mysqlclient error 때문에 굉장히 헤멧다.. python은 계속 최신의 것들이 업데이트 되기 때문에 버전에 민감하고,, 이런 부분이 쥰나게 빡치지만 그래도 편리함이 압승이다..

• admin에 대한 기본적인 설정들, 기본적으로 꼭 필요한 table들이 자동으로 뙇 된다.

setting - Installed_apps

• setting에 있는 installed_apps는 현재 Django 인스턴스에서 활성화된 모든 Django 어플리케이션들의 이름이 담겨 있습니다. 앱들은 다수의 프로젝트에서 사용될 수 있고, 다른 프로젝트에서 쉽게 사용될 수 있도록 패키징하여 배포할 수 있습니다!

• 기본적으로 딸려오는 앱들은 아래와 같다! 사용하기 편하도록, 기본제공이 된다!

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

• 기본앱을 사용하기 싫으면 '마이그레이션' 하기 전에 주석 또는 지워야 쓸모없는 table들을 방지할 수 있다.

django Migration (마이그레이션)

• 장고 공식 문서에서는 마이그레이션이 모델의 변경 내역을 DB 스키마에 적용시키는 장고의 방법이라고 설명하고 있다.

• 장고는 ORM을 사용하기 때문에 models.py와 클래스를 통해 DB 스키마를 생성하고 컨트롤 하게 되는데, 이 때 DB 스키마를 git처럼 버전으로 나눠서 관리 할 수 있게 해 주는 시스템이라 생각하면 된다.

• 즉 하나의 마이그레이션 파일은 해당 마이그레이션이 생성된 시점의 모델의 구조(DB의 스키마)를 담고 있습니다.

• python manage.py makemigrations app_name 명령어를 통해 마이그레이션을 진행한다.

  • 뒤에 app_name을 입력하면 해당 app에 대해서만 마이그레이션을 생성하고 app_name을 생략하면 전체 app에 대해서 마이그레이션을 생성한다.(단, 프로젝트 생성 후 처음 하는 migrate 작업을 위한 마이그레이션을 생성할 때는 app_name을 생략해야 한다.)

• python manage.py migrate [app_name] [migration_name] 명령어를 통해 model의 변경사항이 makemigrations된 것을 실제로 적용(migrate)한다.

  • makemigrations와 같이 app_name을 지정해서 특정 app만 migrate 할 수 있으며 app_name 뒤에 마이그레이션 파일의 이름을 지정하면 해당 번호(버전)의 마이그레이션을 적용하게 된다. 즉 이전 버전으로 되돌리는 것도 가능하다.

• python manage.py showmigrations [app_name] 명령어를 통해 해당 프로젝트의 마이그레이션 적용 여부를 한 눈에 볼 수 있다. 아래 이미지는 app_name을 생략해 전체 프로젝트에 대한 적용 여부를 본 것이다.

• python manage.py sqlmigrate app_name migration_name 명령어를 통해 make된 마이그레이션 파일(migration_name)의 실제 SQL 구문 구성이 어떻게 되는지 보여준다.
  • django는 ORM이라 RAW query를 설계하지 않기 때문에 디버깅용으로 많이 사용한다.
• 마이그레이션 참조 블로그