Django

Django 1.7リリース!ついにマイグレーションを公式サポート

  • このエントリーをはてなブックマークに追加
  • Pocket
  • LINEで送る
django

PythonのWebフレームワークであるDjangoバージョン1.7が9月にリリースされました。
まだ日本語の情報がほとんどないようなので、共有していきたいと思います。

PythonのWebフレームワーク Django

RubyのRails、PythonのDjango。どちらも優れたフレームワークです。

Django 1.7の新機能で目玉となるのがMigration(マイグレーション)です。
いよいよDjangoでも(Rubyのように)Migrationが公式サポートされました。

Migrationって?

Djangoではモデルという概念でデータベースのスキーマを定義することができます。
例えば、nameというフィールドを持つProductモデルを定義する場合は、以下のモデルを記述します。

class Product(models.Model):
    name = models.CharField("Name", max_length=30)

Djangoではこのモデルから、以下のようなデータベーステーブルを自動的に作成してくれます。

CREATE TABLE myapp_product (
    "id" serial NOT NULL PRIMARY KEY,
    "name" varchar(30) NOT NULL,
);

でも、実際に開発を進めていくうちに、モデルを変更したくなってきます。
例えば、descriptionというフィールドをモデルに追加したり。

class Product(models.Model):
    name = models.CharField("Name", max_length=30)
    description = models.CharField("Description", blank=True, null=True, max_length=50)

こういう場合、データーベースのスキーマを変更する必要があります。
以下のような、スキーマを変更するSQLを生成する必要があります。

ALTER TABLE myapp_product ADD COLUMN description varchar(50);

このようなデータベースのスキーマを変更することをMigrationと呼びます。

何が新しくなったの?

これまでDjangoは、新規でモデルをデータベーステーブルに作成するところまではやってくれましたが、スキーマの変更をするMigrationについてはサポートしていませんでした。
そのため、Migrationをするためのサードパーティのツールを別途インストールする必要がありました。Southというツールが一番有名でよく使われています。
もうDjangoをインストールしたら、その次はSouthをインストール、というくらい必須ツールでした。
Django 1.7では、MigrationがDjangoで公式にサポートされるようになりました。もうSouthをインストールする必要はないんですね。

Migrationの使い方

コマンドの説明

1.7ではMigrationに関するコマンドが3つ用意されています。

makemigrations
モデルの定義にもとづいてスキーマの差分を検出して、差分情報を記録したmigrationファイルを生成します
migrate

migrationファイルにもとづいて、データベースにスキーマの変更を適用します。逆に過去の状態に戻したりもできます。
sqlmigrate
migrationで生成されるSQL文を表示して、確認できます。

やってみよう

1. まず普通にテーブル作成

さっきのProductモデルを使って、データベースにテーブルを作成してみます。
↓ モデルはさっきと同じ、nameフィールドだけのProductモデル。

class Product(models.Model):
    name = models.CharField("Name", max_length=30)

↓ makemigrationsコマンドでmigrationファイルを生成します。

$ python manage.py makemigrations

Migrations for 'myapp':
  0001_initial.py:
    - Create model Product

migrationファイルが生成されたというメッセージが表示されています。
実際に、アプリディレクトリの中のmigrationsフォルダの中を見ると、たしかに0001_initial.pyというmigrationファイルが生成されています。

さあ、データベースにテーブルを作成しましょう。
↓ migrateコマンドでmigrationファイルに記録されている情報をデータベースに反映させます。

$ python manage.py migrate

Operations to perform:
  Apply all migrations: sessions, admin, myapp, auth, contenttypes
Running migrations:
  Applying myapp.0001_initial... OK

無事にデータベースにテーブルが作成されました!

2. そしてスキーマ変更

Productモデルにdescriptionフィールドを追加して、スキーマを変更してみましょう。
↓ モデルはこうなります。

class Product(models.Model):
    name = models.CharField("Name", max_length=30)
    description = models.CharField("Description", blank=True, null=True, max_length=50)

↓ モデルを編集したら、同様にmakemigrationコマンドをたたきます。

$ python manage.py makemigrations

Migrations for 'myapp':
  0002_product_description.py:
    - Add field description to product

すると、0002_product_description.pyというmigrationファイルが生成されました。このmigrationファイルに前回モデルとのスキーマ差分が記録されています。

↓ 最後にmigrateコマンドで、データベースにスキーマ変更を適用させます。

$ python manage.py migrate

Operations to perform:
  Apply all migrations: sessions, admin, myapp, auth, contenttypes
Running migrations:
  Applying myapp.0002_product_description... OK

無事にデータベースのテーブルが更新されました!
モデルのスキーマを変更したら、まずmakemigrations、そしてmigrate。簡単ですね。

SQLを確認してみよう

sqlmigrateコマンドを使えば、migrationファイルから、どんなSQLが発行されるのかを調べることができます。

↓ 0001_initial.pyから発行されるSQLを調べます。

$ python manage.py sqlmigrate myapp 0001

BEGIN;
CREATE TABLE "myapp_product" ("id" integer NOT NULL PRIMARY KEY AUTOINCREMENT, "name" varchar(30) NOT NULL);
COMMIT;

モデル定義の通り、テーブルを作成していることが確認できますね。

↓ スキーマに変更を加えた0002_product_description.pyから発行されるSQLも調べてみます。

$ python manage.py sqlmigrate product 0002

BEGIN;
ALTER TABLE "myapp_product" ADD COLUMN "description" varchar(50) NULL;
ALTER TABLE "myapp_product" ALTER COLUMN "description" DROP DEFAULT;
COMMIT;

きちんとスキーマ変更がされていることが確認できますね。

最後にひとこと

日本ではDjango使っている人って本当に少ないですが(日本語情報が少ないせい?)、RubyのRailsと同じくらい便利なフレームワークだと思います。アップデートも活発に行われていますので、PythonでWebアプリを作りたい方はぜひ試してみてください。

  • このエントリーをはてなブックマークに追加
  • Pocket
  • LINEで送る

コメントを残す

*