Django公式 チュートリアル その２

Djangoをマスターしたいので、

チュートリアルにて一連の作業を学びます。

関連記事

• Django 仮想環境からインストールまで
• Django 公式チュートリアル
• Django公式 チュートリアル その１
• Django公式 チュートリアル その２
• Django公式 チュートリアル その３
• Django公式 チュートリアル その４
• Django公式 チュートリアル その５
• Django公式 チュートリアル その６

（個人的な学習ノートです）

前回Djangoのインストールから仮想環境の設定を行いました。

apist.hateblo.jp

Django公式　チュートリアル　その１の記事です↓ 

apist.hateblo.jp

そのままチュートリアルに進みます！

「はじめてのDjangoアプリ作成　その２」

学習環境

macOS Sierra 10.12

python3.6

Django1.11

XAMPP

  MySQL（MariaDB10.1.21）

テキストエディッタ：ATOM

参考サイト

はじめての Django アプリ作成、その2 | Django documentation | Django

上記サイトに沿って進めます。

データベースの設定やってみっけ？

Django の設定を表現するモジュールレベルの変数を持つ通常の Python モジュール

・デフォルトの設定では SQLite

・単に Django を試してみたいだけなら、これが一番簡単な選択

・本番の環境で使う場合、頭痛の種となるため、PostgreSQL などのデータベースがオヌヌメ

本番環境で、MySQLを使いたいのですが・・・。

色々悩んだ挙句、MySQLにて挑戦みっかな

参考サイト

qiita.com

おやつにバナナは入りません！（必要なインストール）

Python製のMySQLクライアントをインストール(PyMySQL)

$ pip install PyMySQL

・・・

Successfully installed PyMySQL-0.7.11

$ pip freeze

Django==1.11

PyMySQL==0.7.11

pytz==2017.2

OKぼくじょ

Python2 で大活躍だった python-mysql は Python3 環境では動かないようなので PyMySQLですが、スクレイピング組んでいる時にものすごく悩んだ記憶が蘇ります。。。

mysite/settings.pyをいじくり倒す（設定）

●ENGINE
'django.db.backends.sqlite3'
'django.db.backends.postgresql'
'django.db.backends.mysql'
'django.db.backends.oracle' のいずれか。

●NAME
データベースの名前。

●USER　PASSWORD　HOST
各種データベース参照


MySQLはXAMMPにて構築済み

データベース名は、「Django」

 DATABASES = {
 　　　　'default': {
　　　　　　'ENGINE': 'django.db.backends.mysql',
　　　　　　'NAME': 'Django',
　　　　　　'USER': 'xxxxx',
　　　　　　'PASSWORD': 'xxxxxx',
　　　　　　'HOST': '',
　　　　　　'PORT': '',
　　　}
} 

下記二行をmysite/manage.pyに追加

import pymysql

pymysql.install_as_MySQLdb()

  これで、MySQLに接続はできるはず！

 

 

公式サイト チュ〜❤️トリアルに戻る

settings.pyを開いているので、その他にもやることやっちゃおうぜって乗りです。

 

TIME_ZONEを自分のタイムゾーンを変更

チュートリアルにどこいぢれってないので、自力で解決

TIME_ZONE = 'Asia/Tokyo'

USE_TZ = False

ついでなので、書いてないけど

LANGUAGE_CODE = 'en-us'

も日本人なら日本語にすっぺ

LANGUAGE_CODE = 'ja'

ドキドキタイム

アプリケーションでは最低１つのテーブルを使う。

上記で設定した設定を活かして、データベースにテーブルを作ります。

$ python manage.py migrate

いくつかのOKが出てエラーなく完了・・・(^_^;)

見えないところで、若干ハマってましたが・・・w

phpMyAdminで確認しましたが、いくつかのテーブルができてました。

migrateコマンド

INSTALL_APPSの設定を参照

&

 mysite/settings.py ファイルのデータベース設定に

従って必要なすべてのデータベースのテーブルを作成

データベースマイグレーションはアプリと共に配布される。

モデルの作成（できればピチピチの・・・）

モデルを定義

 追加的なメタデータとともにデータベースのレイアウトを行う、必須の作業。

開発する簡単な poll アプリケーション

投票項目 (Question) と選択肢 (Choice) の二つのモデルを作成

Poll には・・・

・質問事項 (question)

・公開日 (publication date)

の情報

Choice には・・・

・選択肢のテキスト

・投票数 (vote)

という二つのフィールド

各 Choice は一つの Question に関連づけられている。

Django では・・・

こうした概念を簡単な Python クラスで表現できます。

polls/models.py ファイルを以下のようにいじり倒します↓

(polls/models.py)

from django.db import models

class Question(models.Model): question_text = models.CharField(max_length=200) pub_date = models.DateTimeField('date published')

class Choice(models.Model): question = models.ForeignKey(Question,on_delete=models.CASCADE) choice_text = models.CharField(max_length=200) votes = models.IntegerField(default=0)

各モデルは一つのクラスで表現

いずれもdjango.db.models.Modelのサブクラス

各モデルには複数のクラス変数があり、個々のクラス変数はモデルのデータベースフィールドを表現。

各フィールドは Fieldクラスのインスタンスとして表現されている。

例） CharField は文字のフィールド　

　　 DateTimeField は日時フィー ルド

こうしたクラスは、各フィールドにどのようなデータ型を記憶させるかをDjangoに教えます。

Fieldインスタンスそれぞれの名前(例: question_text や pub_date)は、機械可読なフィールド名です。このフィールド名はPythonコードで使うとともに、データベースも列の名前として使う。

Fieldの第一固定引数には、オプションとして人間可読なフィールド名も指定可。

このフィールド名は Django の二つの内省機能で使う他、ドキュメントとしての役割も。

人間可読なフィールド名を指定しない場合、 Django は機械可読な名前を使う。

上の例では、 Question.pub_date にだけ人間可読なフィールド名を指定。

モデルの他のフィールドでは、フィールドの機械可読な名前は人間可読な名前としても十分なので定義してません。

Fieldクラスの中には必須の引数を持つものもあり。

例）~django.db.models.CharField には max_lengthを指定する必要があり。

       この引数はデータベーススキーマで使われる他、

       後で述べるバリデーションでも使われま す。

Fieldはいつくかオプションの引数も取れます。

今回の場合、 `votes の default 値を 0 に設定しました。

ついに、 ForeignKeyを使用したリレーションシップの記述が定義されました。

これは、それぞれの``Choice`` が一つの``Question``に関連付けられていることをDjangoに伝えます。

Djangoは多対一、多対多、そして一対一のような一般的なデータベースリレーションシップすべてをサポートします。

モデルを有効にする（ピチピチの・・・）

ほんのわずかなコードをモデルに書くだけで、 Django はたくさんの情報を受け取れる。

このコードを使って、 Django は:

・アプリケーションのデータベーススキーマを作成 (CREATE TABLE 文を実行) 

・Question や Choice オブジェクトに

　Python からアクセスするためのデータベー ス API を作成できる。

その前に polls アプリケーションをインストールしたことをプロジェクトに教える必要があるのでサクッとやってみっぺか。

プロジェクトにあるアプリケーションを含めるために、構成クラスへの参照をINSTALL_APPS設定に追加。

PollsConfigクラスは、

　polls/apps.pyにあるので、

　ドットでつながれたパスは、'polls.apps.PollsConfig'  

mysite/settings.pyを編集し、 INSTALL_APPS設定にドットでつながれたパスを追加してみる。

(mysite/settings.py)

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

Django に polls アプリケーションの存在を表明したことになる。

以下のコマンドを実施

$ python manage.py makemigrations polls

実行すると以下の表示される

Migrations for 'polls':

  polls/migrations/0001_initial.py

    - Create model Choice

    - Create model Question

    - Add field question to choice

makemigrationsを実行すると、Djangoにモデルに変更があったこと(この場合、新しいものを作成しました)を伝え、そして変更をマイグレーションの形で保存するしてくれる。

マイグレーションはDjangoがモデル(そしてデータベーススキーマでもあります)の変更をディスク上のファイルに保存する方法。

新しいモデルをマイグレーションのファイル polls/migrations/0001_initial.py から読むことも出来る。

安心して下さい、Djangoが作成する度にマイグレーションのファイルを読む必要はないが、Djangoが行った変更を手動で微調整したいというときのために人間可読なファイルとして設計されてるらしい。

これは自動でデータベーススキーマを管理するためのマイグレーションを実行するとのコマンド。

migrateと呼ばれ、あっという間に完了が、最初は、マイグレーションがどんなSQLを実行するのか見てみましょう。

sqlmigrateコマンドはマイグレーションの名前を引数にとってSQLを返します。

ってわけで、以下のコマンドを実施

$ python manage.py sqlmigrate polls 0001

以下の表示されたw

BEGIN;

--

-- Create model Choice

--

CREATE TABLE `polls_choice` (`id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY, `choice_text` varchar(200) NOT NULL, `votes` integer NOT NULL);

--

-- Create model Question

--

CREATE TABLE `polls_question` (`id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY, `question_text` varchar(200) NOT NULL, `pub_date` datetime(6) NOT NULL);

--

-- Add field question to choice

--

ALTER TABLE `polls_choice` ADD COLUMN `question_id` integer NOT NULL;

ALTER TABLE `polls_choice` ADD CONSTRAINT `polls_choice_question_id_c5b4b260_fk_polls_question_id` FOREIGN KEY (`question_id`) REFERENCES `polls_question` (`id`);

COMMIT;

（使用データベース　MySQL系MariaDB10.1.21）

以下の注意点

• テーブル名はアプリケーションの名前 (polls) とモデルの小文字表記 の question と choice を組み合わせて自動的に生成。(オーバライド可)

• 主キー (primary key, ID) は自動的に追加 (オーバライド可)。

• Django は外部キーのフィールド名に "_id" を追加(オーバライド可)。

• これはあなたが使用しているデータベースに合わせて、auto_increment (MySQL)、 serial (PostgreSQL) もしくは integer primary key autoincrement` (SQLite) のようなデータベースに特化した型が自動的に選択され生成。フィールド名のクォーティングをダブルクォートにするか、シングルクォートにするかも同じように扱れる。

• sqlmigrateコマンドは実際にはデータベースにマイグレーションを実行しません。ただ、Djangoが必要としているSQLが何であるかをスクリーンに表示するだけ。これはDjangoが何をしようとしているかを確認したり、データベース管理者に変更のためのSQLスクリプトを要求されているときに役に立ちます。

もし興味があれば 「python manage.py check」を実行可。これはマイグレーションを作成したりデータベースにふれることなくプロジェクトになんの問題がないか確認します 。

試しに・・・

$ python manage.py check

System check identified no issues (0 silenced).

migrateを再度実行し、 モデルのテーブルをデータベースに作成

$ python manage.py migrate

Operations to perform:

  Apply all migrations: admin, auth, contenttypes, polls, sessions

Running migrations:

  Applying polls.0001_initial... OK

 migrateコマンドはすべての適用されていないマイグレーション(Djangoはデータベース内の``django_migrations``と呼ばれる特別なテーブルを利用してどれが適用されているかを追跡)を捕捉してデータベースに対してそれを実行

- 重要なのは、モデルに対して行った変更はデータベースのスキーマに同期するということ。

マイグレーションは、データベースやテーブルを削除しまた新しいものを作成する必要なくプロジェクトを開発するように、いつでもモデルを変更可能とする強力なツール

- データを失うことなしにデータベースをライブでアップグレードするよう特化。

今は、モデルの変更を実施するための3ステップガイドを覚えておく：

• モデルを変更する (models.py の中の)
• これらの変更のためのマイグレーションを作成するために python manage.py makemigrationsを実行
• データベースにこれらの変更を適用するために python manage.py migrate を実行

マイグレーションの作成と適用のコマンドが分割されている理由

マイグレーションをバージョン管理システムにコミットし、アプリとともに配布するため。

これによって、あなたの開発が容易になるだけでなく、他の開発者や本番環境にとって使いやすいものになる。

Django Admin

• 「コンテンツの作成者 (content publisher)」と「公開 (public) 」サイトをきわめて明確に区別
• サイト管理者向けの一元化されたコンテンツ編集インタフェースを提供

管理ユーザーの作成

下記のように入力

$ python manage.py createsuperuser

希望のユーザー名を入力

Username (leave blank to use 'kenta'): 

希望のメールアドレスを入力

Email address: 

希望のパスワード

Password: 

上で入力したパスワードをもう一度

Password (again): 

Superuser created successfully.

開発サーバの起動

Django adminサイトはデフォルトで有効化されたので開発サーバを起動して確認

$ python manage.py runserver

http:// http://127.0.0.1:8000/admin/ へアクセスしてログイン画面を確認

下記のような画面が出たら成功

admin画面へ

先ほど登録したUSERとPASSWORDを入力してログインを押すと以下のような画面となる。

グループとユーザーといういくつかのタイプの編集可能なコンテンツが閲覧できるはず。

これらはDjangoに含まれる認証フレームワーク django.contrib.auth によって提供。

Poll アプリを admin 上で編集できるようにする

adminに”Question”オブジェクト達はadmin インタフェースを持つことを伝える必要があるため、これを行うために、ファイル polls/admin.py を開いてこのように編集。

(polls/admin.py)

from django.contrib import admin
from .models import Question

admin.site.register(Question)

 ファイル更新後、ブラウザの更新を行うと下記のような画面となる。

 “Questions”をクリック。

questionsのための”change list”ページが表示される。

これで、管理画面から編集することが可能となりました。

（注意点）

1. フォームは Question モデルから自動的に生成
2. モデルのフィールドの型 (DateTimeField 、 CharField など) によって適切な HTML 入力ウィジェッ トが対応。各種のフィールドには Django 管理サイトでデー タを表示する方法が定義されている。
3. 各 DateTimeField は JavaScript ショートカットがついている。日付 (dates) のカラムには「今日 (today)」 へのショートカットとカレンダーポップアップボタン。時刻 (times) には「現在 (now)」へのショートカットと、よく入力される時刻のリストを表示するポップアップボタンがある。

ページの末尾の部分には操作ボタンがいくつか表示:

• 保存 (Save) – 変更を保存して、このモデルのチェンジリストのページに戻る。

• 保存して編集を続ける (Save and continue editing) – 変更を保存して、このオブジェクトの編集ページをリロード。

• 保存してもう一つ追加 (Save and add another) – 変更を保存して、このモデルのオブジェクトを新規追加するための空の編集ページをロード。

• 削除 (Delete) – 削除確認ページを表示。

次回は、「初めてのDjangoアプリ作成、その３」に 取り掛かかります。

関連記事

• Django 仮想環境からインストールまで
• Django 公式チュートリアル
• Django公式 チュートリアル その１
• Django公式 チュートリアル その２
• Django公式 チュートリアル その３
• Django公式 チュートリアル その４
• Django公式 チュートリアル その５
• Django公式 チュートリアル その６