Django2 入門チュートリアル – CRUDの基本を簡単なサンプルで学ぶ – 2 – モデルとマイグレーション

このチュートリアルはDjango2 入門チュートリアル – CRUDの基本を簡単なサンプルで学ぶ – 1 – 環境準備の続きです。

前回作成した Django プロジェクト myblog 内に簡単なブログ・アプリを作りながら、Django 2 のCRUDの基本を学んでいきましょう。

PCのシャットダウンや deactivate コマンドで venv 仮想環境を終了してしまった場合は、もう一度仮想環境を有効化してください。この記事は前回作った仮想環境 myenv にて実行しています。

 

有効化から開発サーバ起動までのコマンドの復習

$ cd myenvのあるディレクトリ

$ source myenv/bin/activate

(myenv) $ cd myblog

(myenv) $ python manage.py runserver

 

アプリケーションの作成

前回作成したプロジェクト(myblog)の中にアプリケーションを作りましょう。次のコマンドを実行するとアプリケーションの雛形ができます。

実行すると blogs というディレクトリが作られ、myblogプロジェクト内のファイルが以下のようになります。

 

このように Django ではコマンドでプロジェクトとアプリケーションの作成を行います。Django の基本中の基本なので、少しでも不明点があるなら、公式チュートリアルはじめての Django アプリ作成、その 1を読み直しましょう。

 

マイグレーションの基礎知識

アプリケーションの雛形ができたところで、モデルの作成とマイグレーションをしましょう。

マイグレーション とは?

Ruby on Rails、Laravel、CakePHP といった Django 以外のWEBアプリケーション・フレームワークを使ったことがあれば、マイグレーションはお馴染みかもしれませんが、はじめての方には理解しにくいため、基本から解説いたします。

マイグレーションとはアプリケーション側のソースコードでデータベースの構築と管理を行う仕組みです。

これだけでは「なんのこっちゃ」ですよね。マイグレーションは過去の課題解決の産物なので、経緯を理解するとスムーズかと思います。

(少し長くて恐縮です…)

今でこそマイグレーションは当たり前のものですが、その普及以前はSQLでテーブル等を直接構築していました。WEBアプリケーションにはDBスキーマ変更がつきものですが、SQLで直接操作することで、変更履歴を管理しにくい、開発環境ひとつ作るにも「手順書」に沿ってSQLを実行しなければならない、さらにはその「手順書」が存在しない or 正しくない…など挙げればキリがないほど多くの問題が発生していました。

これらの問題を解消するため、アプリケーション側のソースコードでデータベースを構築・管理する仕組み「マイグレーション」が登場しました。マイグレーションにより、わずかなコマンドで「正しいデータベース」を即座に構築できるようになり、データベースの変更履歴管理もできるようになりました。Git ほど多機能ではないですが、コマンドで変更前の構造に戻す、といったことも可能です。

マイグレーションを導入していると(例えば SQLite から MySQL へと)データベースの種類を変更する場合も比較的スムーズに移行できます。

 

Django2のマイグレーションはモデル駆動

Django2のマイグレーションは少しばかり特殊です。Ruby on Rails、Laravel、CakePHP といった人気フレームワークとは仕組みが違うので注意しましょう。どう違うかは公式ドキュメントにある通りです。

モデルは、手持ちのデータに対する唯一の決定的なソースです。モデルには自分が格納したいデータにとって必要不可欠なフィー ルドと、そのデータの挙動を収めます。 Django は DRY 則に従っています。 Django のモデルの目的は、ただ一つの場所でデータモデルを定義し、そこから自動的に色々なものを派生させることにあります。

これはマイグレーションを含みます – 例えば、 Ruby On Rails と違って、マイグレーションは完全にモデルのファイルから生成されます。マイグレーションは本質的には単なる履歴です。 Django はデータベースのスキーマをアップデートしながら履歴を進んでいき、現在のモデルに合致させることができます。

https://docs.djangoproject.com/ja/2.0/intro/tutorial02/ より引用

Django2ではマイグレーションの起点が必ずモデル(モデルのファイル)となっており、他のWEBアプリケーションフレームワークとはワークフローや機能が異なることに注意しましょう。

 

モデルの作成とマイグレーション

モデルの作成

blogs/models.py を以下のように編集します。

Post モデルの補足

django.db.models.Model を継承し、ブログの投稿データを扱うモデル Post を定義しています(django.db.models.Model を継承するのを忘れずに!)。各プロパティは title: 記事タイトル、text: 記事本文、author: 執筆者、created_at: 作成時刻、updated_at: 更新時刻となります。

ForeignKey により author と auth.User を many-to-one リレーションしています(公式ドキュメント ForeignKey)。突然 auth.User というモデルが出てきていますが、auth.User は Django2 のビルトイン・モデルです。

時刻については auto_now_add、auto_now という自動更新オプションを指定しています。これにより INSERT / UPDATE の都度、手動で時刻データをセットする作業を省略できます。公式ドキュメント DateTimeField

PHPフレームワークでは1モデル1ファイル(1クラス1ファイル)で管理することが多いですが、Djangoでは複数のモデルを1ファイル内に定義してもOKです。ただし、アプリの規模が大きくなったら分割した方がよいでしょう。

モデルの有効化

続いてプロジェクトの設定ファイル myblog/settings.py 中にある INSTALLED_APPS にアプリケーション(blogs)を追加しましょう。これにより先ほど作成した Post モデルが有効化されます。

myblog/settings.py

この作業はDjangoの基本中の基本です。不明な場合にははじめての Django アプリ作成、その2を読み直しましょう。

マイグレーション

モデルの作成と有効化を終えたら最後にマイグレーションです。マイグレーションはお決まりのコマンドを打つだけのルーチン作業ですが、以下の作業で少しでも不明点があるならはじめての Django アプリ作成、その2を読み直しましょう。

blogsアプリのモデルファイル(blogs/models.py)をもとにマイグレーション・ファイルが生成される。※下図は実際の画面キャプチャー

makemigrations

マイグレートすると、myblog/db.sqlite3 という SQLite のデータファイルができるので、DB Browser for SQLite のようなGUI管理ツールでチェックしてみましょう。

以上でモデル作成とマイグレーションが完了です。次回は Django Adminサイトについてのチュートリアルとなります。

この記事が役に立ったら是非シェアください!

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です