venvを使って仮想環境構築しDjangoを利用する。

$ mkdir django
$ python -m venv django/
$ source django/bin/activate

仮想環境内でpipでdjangoをインストール

$ pip install django

以下、公式のチュートリアルに沿ってアプリを作成しながら必要事項をメモしていく。

• Django チュートリアル

プロジェクトの作成

$ django-admin startproject app01

• プロジェクトを格納するapp01ディレクトリが作られる
• app01内には「app01」と「manage.py」がある
  • 内部のapp01はプロジェクトのメインディレクトリ。設定ファイルやURLディスパッチャの設定ファイルが格納されている。
  • manage.pyはプロジェクト管理用のユーティリティ

Djangoは開発用のWebサーバを持っている。

app01/settings.pyにアクセス許可の設定

ALLOWED_HOSTS = ["*"]

サーバの起動

$ python manage.py runserver 0:8000

ポート番号8000で待ち受け。0:ですべてのホストから接続を受け付ける。

コマンドでの待ち受けIPを指定するとローカルホストからのみ接続できる。ここでは別ホスト上に開発環境があるので、接続されているインターフェースにバインドする。0を指定すればすべてのインターフェイスにバインド。

起動コマンドでIPアドレスにアサインすることと、設定ファイルの接続許可が両方正しく設定されて、初めて外部から接続できる。うまく起動できれば、http://[IP Address]:8000/でテストサーバに接続され、ロケット打ち上げが表示される。

app01/settings.pyの基本設定

言語やタイムゾーンを設定

LANGUAGE_CODE = 'ja'                                                                                                           
TIME_ZONE = 'Japan'

プロジェクト内に具体的に機能するアプリケーションを作成。

reportという名前のアプリケーションを作成する

$ python manage.py startapp report

• app01（プロジェクトの親ディレクトリ）内にreportディレクトリが作成され、アプリケーションに関するファイル一式が格納される。

Viewはアプリケーションのロジック、処理を行う中心的な部分。データの加工やテンプレートの呼び出しなど、様々な処理を担当する。

viewの本体。とりあえず単純に文字を表示するだけ。

from django.shortcuts import render
from django.http import HttpResponse

def index(request):
    return HttpResponse("Hello, Django.") 

URLのディスパッチ設定。アプリケーションレベルのURLはここでディスパッチする。このファイルは、プロジェクトレベルのURLディスパッチにインクルードして使う。アプリケーション作成時には自動作成されない。

urlpatternsにURLとViewの対応を設定する。ここでは「''」でルートディレクトリへのアクセスをviews.pyのindex関数と対応づける。

from django.urls import path
from . import views

urlpatterns = [
    path('', views.index, name='index'),
]

プロジェクトレベルのURLディスパッチ

include関数を読み込んで、アプリケーションレベルのURLディスパッチ設定ファイルを読み込むように設定する。

ここでは/report/以下のURLはreport/urls.pyを読み込んで処理する。

from django.contrib import admin
from django.urls import path, include

urlpatterns = [
    path('report/', include('report.urls')),
    path('admin/', admin.site.urls),
]

以上を設定すると、http://[IP Address]:8000/report/で「Hello, Django.」が表示される。

データベースからデータを呼び出したり保存したりする。直接クエリを発行するのではなく、オブジェクトを介して操作。

開発途中は取りあえずSQLiteを利用する。本番環境ではPostgreSQLなりMySQLに切り替える。データベースの定義はDjangoが自動的に生成してくれるので、バックエンドはあまり意識する必要はない。とりあえず、設定ファイルだけ確認しておく。

app01/app01/settings.py

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': os.path.join(BASE_DIR, 'db.sqlite3'),
    }
}

標準ではSQLiteが使われる。

Djangoのフレームワークとして必要なテーブルを作成し準備を整える。

$ python manage.py migrate

設定ファイルを参照し、必要なテーブルをデータベースに生成する。

初期に必要なテーブルは、settings.pyのINSTALLED_APPに列挙されているフレームワークの組み込みアプリケーションを中心に生成される。自分で作成したアプリケーションでモデルを作成すると、migrateによって必要なテーブルが作成される。

モデルの定義を作成する。

app01/report/models.py

from django.db import models

class Choice(models.Model):
    categ_code = models.CharField(max_length=10)
    categ = models.CharField(max_length=200)
    hs_code = models.CharField(max_length=10)
    hs = models.CharField(max_length=200)

    def __str__(self):
        return self.categ + self.hs

class Report:
    hs_code = models.ForeignKey(Choice, on_delete=models.PROTECT)
    report_field01 = models.CharField(max_length=1000)
    report_field02 = models.CharField(max_length=1000)
    report_field03 = models.CharField(max_length=1000)

    def __str__(self):
        return str(hs_code) + self.report_field01

1つのテーブルは1つのクラスとして定義される。クラスのサブクラスや変数で様々な挙動が設定できる。最も基本的な設定として、クラスの変数がデータベースに対応する。変数にデータの型や外部キーなどを設定していく。

クラス内の「str」関数は、モデルのオブジェクト表現となる。管理画面で一覧表示するときなどに使われる文字列を定義できる。

migrationでテーブルを管理するために、フレームワークに作成したアプリケーションを認識させる必要がある。先に示したsettings.pyのINSTALLED_APPに列挙すればよい。

app01/app01/settings.py

INSTALLED_APPS = [
    'report.apps.ReportConfig',
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
]

ここで記述するのはアプリケーションのクラス名となる。プロジェクトディレクトリからクラスをたどって記述する。ここでは、reportアプリケーションのapps.pyファイルに定義されているReportConfigクラスとなる。このクラスはstartappでアプリケーションを作成した際に自動的に生成される。

定義したモデルに対応してバックエンドのデータベースを作成する。

$ python manage.py makemigrations report

makemigrationsコマンドでモデルの変更を検出し、migrationの定義ファイルを生成する。ポイントは、この時点でデータベースへの変更は一切行われていない点である。migrationの定義内容は、report/migrations/xxxx.pyに生成される。

migrationで実行される具体的なSQLを確認する。

$ python manage.py sqlmigrate report 0001

最後の引数はmigrationの定義ファイルのファイル名に対応する。何度もモデルを変更すると、そのたびにmigrationが生成され、履歴が残るようになっているようだ。対象となるファイルのmigration内容を確認するために、ファイルの番号を指定する。

必要なテールが意図通りに作成されることが確認できれば、再度migrationを行いバックエンドのデータベースに反映させる。

$ python manage.py migrate