2018-12-06

Django マイグレーション完全に理解した (ケーススタディ編) 🍎

今回は基礎編に引き続き、ケーススタディ編をお送りします。

この記事は BeProud Advent Calendar 2018 7日目の記事ということにします。 BeProud Advent Calendar 2018 - Adventar普段忙しくてなかなかブログを書けない人のケツを叩くための BeProud アドベントカレンダーです内容は技術的なことなら何でもOK BeProud に関係してる人なら誰でも、としたいんですが枠が限られているので [BeProud](https://www.beproud.jp/) の社員か元社員の方に優先的に入ってもらいたい気持ちですカレンダー作成者でも枠の登録削除はできないようなので良識の範囲で登録してください何かあれば [Twitter](https://twitter.com/crohaco) で連絡くださいhttps://adventar.org/calendars/3338

公開日を分けるのがめんどくさいので 12/6 の基礎編に合わせて公開してます。事故ではありません 🙆‍

この記事では軽い応用から基礎編だけではカバーしきれなかった少し特殊なケースを取り上げます。

少しだけ長いので、必要な部分だけ参照すれば良いと思います 👻

サンプルコードを以下においたので見てくれやで。zipはもうない。(Next移行で死にました) GitHub - righ/django-migration-case-studiesContribute to righ/django-migration-case-studies development by creating an account on GitHub.https://github.com/righ/django-migration-case-studies

🤔 既存テーブルがある状態で初期マイグレーションをする

1.7 未満の Django からアップグレードした
Django 以外のフレームワークから移行してきた

など様々な要因でテーブルの有無とマイグレーションの不整合は発生します。

ここでは、Django 1.6 (マイグレーションがないバージョン) 以前から 2.1 へ移行してきたという気持ちでやってみたいと思います。

1.6で初期化
スキーマ

$ ./manage.py syncdb
Creating tables ...
Creating table django_admin_log
Creating table auth_permission
Creating table auth_group_permissions
Creating table auth_group
Creating table auth_user_groups
Creating table auth_user_user_permissions
Creating table auth_user
Creating table django_content_type
Creating table django_session
Creating table products_category
Creating table products_product
Creating table products_price
Creating table sales_sales
Creating table sales_summary

You just installed Django's auth system, which means you don't have any superusers defined.
Would you like to create one now? (yes/no): no
Installing custom SQL ...
Installing indexes ...
Installed 0 object(s) from 0 fixture(s)

sqlite> .schema
CREATE TABLE IF NOT EXISTS "django_admin_log" (
    "id" integer NOT NULL PRIMARY KEY,
    "action_time" datetime NOT NULL,
    "user_id" integer NOT NULL,
    "content_type_id" integer,
    "object_id" text,
    "object_repr" varchar(200) NOT NULL,
    "action_flag" smallint unsigned NOT NULL,
    "change_message" text NOT NULL
);
CREATE TABLE IF NOT EXISTS "auth_permission" (
    "id" integer NOT NULL PRIMARY KEY,
    "name" varchar(50) NOT NULL,
    "content_type_id" integer NOT NULL,
    "codename" varchar(100) NOT NULL,
    UNIQUE ("content_type_id", "codename")
);
CREATE TABLE IF NOT EXISTS "auth_group_permissions" (
    "id" integer NOT NULL PRIMARY KEY,
    "group_id" integer NOT NULL,
    "permission_id" integer NOT NULL REFERENCES "auth_permission" ("id"),
    UNIQUE ("group_id", "permission_id")
);
CREATE TABLE IF NOT EXISTS "auth_group" (
    "id" integer NOT NULL PRIMARY KEY,
    "name" varchar(80) NOT NULL UNIQUE
);
CREATE TABLE IF NOT EXISTS "auth_user_groups" (
    "id" integer NOT NULL PRIMARY KEY,
    "user_id" integer NOT NULL,
    "group_id" integer NOT NULL REFERENCES "auth_group" ("id"),
    UNIQUE ("user_id", "group_id")
);
CREATE TABLE IF NOT EXISTS "auth_user_user_permissions" (
    "id" integer NOT NULL PRIMARY KEY,
    "user_id" integer NOT NULL,
    "permission_id" integer NOT NULL REFERENCES "auth_permission" ("id"),
    UNIQUE ("user_id", "permission_id")
);
CREATE TABLE IF NOT EXISTS "auth_user" (
    "id" integer NOT NULL PRIMARY KEY,
    "password" varchar(128) NOT NULL,
    "last_login" datetime NOT NULL,
    "is_superuser" bool NOT NULL,
    "username" varchar(30) NOT NULL UNIQUE,
    "first_name" varchar(30) NOT NULL,
    "last_name" varchar(30) NOT NULL,
    "email" varchar(75) NOT NULL,
    "is_staff" bool NOT NULL,
    "is_active" bool NOT NULL,
    "date_joined" datetime NOT NULL
);
CREATE TABLE IF NOT EXISTS "django_content_type" (
    "id" integer NOT NULL PRIMARY KEY,
    "name" varchar(100) NOT NULL,
    "app_label" varchar(100) NOT NULL,
    "model" varchar(100) NOT NULL,
    UNIQUE ("app_label", "model")
);
CREATE TABLE IF NOT EXISTS "django_session" (
    "session_key" varchar(40) NOT NULL PRIMARY KEY,
    "session_data" text NOT NULL,
    "expire_date" datetime NOT NULL
);
CREATE TABLE IF NOT EXISTS "products_category" (
    "id" integer NOT NULL PRIMARY KEY,
    "name" varchar(30) NOT NULL,
    "created_at" datetime NOT NULL
);
CREATE TABLE IF NOT EXISTS "products_product" (
    "id" integer NOT NULL PRIMARY KEY,
    "name" varchar(255) NOT NULL,
    "category_id" integer NOT NULL REFERENCES "products_category" ("id"),
    "created_at" datetime NOT NULL,
    "updated_at" datetime NOT NULL,
    "deleted_at" datetime
);
CREATE TABLE IF NOT EXISTS "products_price" (
    "id" integer NOT NULL PRIMARY KEY,
    "price" integer NOT NULL,
    "product_id" integer NOT NULL REFERENCES "products_product" ("id"),
    "effective_date_start" datetime,
    "effective_date_end" datetime
);
CREATE TABLE IF NOT EXISTS "sales_sales" (
    "id" integer NOT NULL PRIMARY KEY,
    "product_id" integer NOT NULL REFERENCES "products_product" ("id"),
    "sold_at" datetime NOT NULL
);
CREATE TABLE IF NOT EXISTS "sales_summary" (
    "id" integer NOT NULL PRIMARY KEY,
    "date" date NOT NULL,
    "total_sales" integer NOT NULL,
    "total_price" integer NOT NULL,
    "unique_user" integer NOT NULL
);
CREATE INDEX "django_admin_log_6340c63c" ON "django_admin_log" ("user_id");
CREATE INDEX "django_admin_log_37ef4eb4" ON "django_admin_log" ("content_type_id");
CREATE INDEX "auth_permission_37ef4eb4" ON "auth_permission" ("content_type_id");
CREATE INDEX "auth_group_permissions_5f412f9a" ON "auth_group_permissions" ("group_id");
CREATE INDEX "auth_group_permissions_83d7f98b" ON "auth_group_permissions" ("permission_id");
CREATE INDEX "auth_user_groups_6340c63c" ON "auth_user_groups" ("user_id");
CREATE INDEX "auth_user_groups_5f412f9a" ON "auth_user_groups" ("group_id");
CREATE INDEX "auth_user_user_permissions_6340c63c" ON "auth_user_user_permissions" ("user_id");
CREATE INDEX "auth_user_user_permissions_83d7f98b" ON "auth_user_user_permissions" ("permission_id");
CREATE INDEX "django_session_b7b81f0c" ON "django_session" ("expire_date");
CREATE INDEX "products_product_6f33f001" ON "products_product" ("category_id");
CREATE INDEX "products_price_7f1b40ad" ON "products_price" ("product_id");
CREATE INDEX "sales_sales_7f1b40ad" ON "sales_sales" ("product_id");

2.1 に移行してきたのでマイグレーションを作って適用してみます。

./manage.py makemigrations products sales
./manage.py migrate

$ ./manage.py makemigrations products sales
Migrations for 'products':
  products/migrations/0001_initial.py
    - Create model Category
    - Create model Price
    - Create model Product
    - Add field product to price
Migrations for 'sales':
  sales/migrations/0001_initial.py
    - Create model Sales
    - Create model Summary

$ ./manage.py migrate
Operations to perform:
  Apply all migrations: admin, auth, contenttypes, products, sales, sessions
Running migrations:
  Applying contenttypes.0001_initial...Traceback (most recent call last):
  File "/venv/lib/python3.7/site-packages/django/db/backends/utils.py", line 83, in _execute
    return self.cursor.execute(sql)
  File "/venv/lib/python3.7/site-packages/django/db/backends/sqlite3/base.py", line 294, in execute
    return Database.Cursor.execute(self, query)
sqlite3.OperationalError: table "django_content_type" already exists

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "./manage.py", line 10, in <module>
    execute_from_command_line(sys.argv)
  File "/venv/lib/python3.7/site-packages/django/core/management/__init__.py", line 381, in execute_from_command_line
    utility.execute()
  File "/venv/lib/python3.7/site-packages/django/core/management/__init__.py", line 375, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/venv/lib/python3.7/site-packages/django/core/management/base.py", line 316, in run_from_argv
    self.execute(*args, **cmd_options)
  File "/venv/lib/python3.7/site-packages/django/core/management/base.py", line 353, in execute
    output = self.handle(*args, **options)
  File "/venv/lib/python3.7/site-packages/django/core/management/base.py", line 83, in wrapped
    res = handle_func(*args, **kwargs)
  File "/venv/lib/python3.7/site-packages/django/core/management/commands/migrate.py", line 203, in handle
    fake_initial=fake_initial,
  File "/venv/lib/python3.7/site-packages/django/db/migrations/executor.py", line 117, in migrate
    state = self._migrate_all_forwards(state, plan, full_plan, fake=fake, fake_initial=fake_initial)
  File "/venv/lib/python3.7/site-packages/django/db/migrations/executor.py", line 147, in _migrate_all_forwards
    state = self.apply_migration(state, migration, fake=fake, fake_initial=fake_initial)
  File "/venv/lib/python3.7/site-packages/django/db/migrations/executor.py", line 244, in apply_migration
    state = migration.apply(state, schema_editor)
  File "/venv/lib/python3.7/site-packages/django/db/migrations/migration.py", line 124, in apply
    operation.database_forwards(self.app_label, schema_editor, old_state, project_state)
  File "/venv/lib/python3.7/site-packages/django/db/migrations/operations/models.py", line 91, in database_forwards
    schema_editor.create_model(model)
  File "/venv/lib/python3.7/site-packages/django/db/backends/base/schema.py", line 312, in create_model
    self.execute(sql, params or None)
  File "/venv/lib/python3.7/site-packages/django/db/backends/base/schema.py", line 133, in execute
    cursor.execute(sql, params)
  File "/venv/lib/python3.7/site-packages/django/db/backends/utils.py", line 100, in execute
    return super().execute(sql, params)
  File "/venv/lib/python3.7/site-packages/django/db/backends/utils.py", line 68, in execute
    return self._execute_with_wrappers(sql, params, many=False, executor=self._execute)
  File "/venv/lib/python3.7/site-packages/django/db/backends/utils.py", line 77, in _execute_with_wrappers
    return executor(sql, params, many, context)
  File "/venv/lib/python3.7/site-packages/django/db/backends/utils.py", line 85, in _execute
    return self.cursor.execute(sql, params)
  File "/venv/lib/python3.7/site-packages/django/db/utils.py", line 89, in __exit__
    raise dj_exc_value.with_traceback(traceback) from exc_value
  File "/venv/lib/python3.7/site-packages/django/db/backends/utils.py", line 83, in _execute
    return self.cursor.execute(sql)
  File "/venv/lib/python3.7/site-packages/django/db/backends/sqlite3/base.py", line 294, in execute
    return Database.Cursor.execute(self, query)
django.db.utils.OperationalError: table "django_content_type" already exists

続いて --fake-initial を使って適用してみます

--fake-initial の適用
スキーマの状態

$ ./manage.py migrate --fake-initial
Operations to perform:
  Apply all migrations: admin, auth, contenttypes, products, sales, sessions
Running migrations:
  Applying contenttypes.0001_initial... FAKED
  Applying auth.0001_initial... FAKED
  Applying admin.0001_initial... FAKED
  Applying admin.0002_logentry_remove_auto_add... OK
  Applying admin.0003_logentry_add_action_flag_choices... OK
  Applying contenttypes.0002_remove_content_type_name... OK
  Applying auth.0002_alter_permission_name_max_length... OK
  Applying auth.0003_alter_user_email_max_length... OK
  Applying auth.0004_alter_user_username_opts... OK
  Applying auth.0005_alter_user_last_login_null... OK
  Applying auth.0006_require_contenttypes_0002... OK
  Applying auth.0007_alter_validators_add_error_messages... OK
  Applying auth.0008_alter_user_username_max_length... OK
  Applying auth.0009_alter_user_last_name_max_length... OK
  Applying products.0001_initial... FAKED
  Applying sales.0001_initial... FAKED
  Applying sessions.0001_initial... FAKED

sqlite> .schema
CREATE TABLE IF NOT EXISTS "auth_group_permissions" (
    "id" integer NOT NULL PRIMARY KEY,
    "group_id" integer NOT NULL,
    "permission_id" integer NOT NULL REFERENCES "auth_permission__old" ("id"),
    UNIQUE ("group_id", "permission_id")
);
CREATE TABLE IF NOT EXISTS "auth_group" (
    "id" integer NOT NULL PRIMARY KEY,
    "name" varchar(80) NOT NULL UNIQUE
);
CREATE TABLE IF NOT EXISTS "auth_user_groups" (
    "id" integer NOT NULL PRIMARY KEY,
    "user_id" integer NOT NULL,
    "group_id" integer NOT NULL REFERENCES "auth_group" ("id"),
    UNIQUE ("user_id", "group_id")
);
CREATE TABLE IF NOT EXISTS "auth_user_user_permissions" (
    "id" integer NOT NULL PRIMARY KEY,
    "user_id" integer NOT NULL,
    "permission_id" integer NOT NULL REFERENCES "auth_permission__old" ("id"),
    UNIQUE ("user_id", "permission_id")
);
CREATE TABLE IF NOT EXISTS "django_session" (
    "session_key" varchar(40) NOT NULL PRIMARY KEY,
    "session_data" text NOT NULL,
    "expire_date" datetime NOT NULL
);
CREATE TABLE IF NOT EXISTS "products_category" (
    "id" integer NOT NULL PRIMARY KEY,
    "name" varchar(30) NOT NULL,
    "created_at" datetime NOT NULL
);
CREATE TABLE IF NOT EXISTS "products_product" (
    "id" integer NOT NULL PRIMARY KEY,
    "name" varchar(255) NOT NULL,
    "category_id" integer NOT NULL REFERENCES "products_category" ("id"),
    "created_at" datetime NOT NULL,
    "updated_at" datetime NOT NULL,
    "deleted_at" datetime
);
CREATE TABLE IF NOT EXISTS "products_price" (
    "id" integer NOT NULL PRIMARY KEY,
    "price" integer NOT NULL,
    "product_id" integer NOT NULL REFERENCES "products_product" ("id"),
    "effective_date_start" datetime,
    "effective_date_end" datetime
);
CREATE TABLE IF NOT EXISTS "sales_sales" (
    "id" integer NOT NULL PRIMARY KEY,
    "product_id" integer NOT NULL REFERENCES "products_product" ("id"),
    "sold_at" datetime NOT NULL
);
CREATE TABLE IF NOT EXISTS "sales_summary" (
    "id" integer NOT NULL PRIMARY KEY,
    "date" date NOT NULL,
    "total_sales" integer NOT NULL,
    "total_price" integer NOT NULL,
    "unique_user" integer NOT NULL
);
CREATE INDEX "auth_group_permissions_5f412f9a" ON "auth_group_permissions" ("group_id");
CREATE INDEX "auth_group_permissions_83d7f98b" ON "auth_group_permissions" ("permission_id");
CREATE INDEX "auth_user_groups_6340c63c" ON "auth_user_groups" ("user_id");
CREATE INDEX "auth_user_groups_5f412f9a" ON "auth_user_groups" ("group_id");
CREATE INDEX "auth_user_user_permissions_6340c63c" ON "auth_user_user_permissions" ("user_id");
CREATE INDEX "auth_user_user_permissions_83d7f98b" ON "auth_user_user_permissions" ("permission_id");
CREATE INDEX "django_session_b7b81f0c" ON "django_session" ("expire_date");
CREATE INDEX "products_product_6f33f001" ON "products_product" ("category_id");
CREATE INDEX "products_price_7f1b40ad" ON "products_price" ("product_id");
CREATE INDEX "sales_sales_7f1b40ad" ON "sales_sales" ("product_id");
CREATE TABLE IF NOT EXISTS "django_migrations" ("id" integer NOT NULL PRIMARY KEY AUTOINCREMENT, "app" varchar(255) NOT NULL, "name" varchar(255) NOT NULL, "applied" datetime NOT NULL);
CREATE TABLE sqlite_sequence(name,seq);
CREATE TABLE IF NOT EXISTS "django_admin_log" ("id" integer NOT NULL PRIMARY KEY AUTOINCREMENT, "action_time" datetime NOT NULL, "object_id" text NULL, "object_repr" varchar(200) NOT NULL, "change_message" text NOT NULL, "content_type_id" integer NULL REFERENCES "django_content_type__old" ("id") DEFERRABLE INITIALLY DEFERRED, "user_id" integer NOT NULL REFERENCES "auth_user__old" ("id") DEFERRABLE INITIALLY DEFERRED, "action_flag" smallint unsigned NOT NULL);
CREATE INDEX "django_admin_log_content_type_id_c4bce8eb" ON "django_admin_log" ("content_type_id");
CREATE INDEX "django_admin_log_user_id_c564eba6" ON "django_admin_log" ("user_id");
CREATE TABLE IF NOT EXISTS "django_content_type" ("id" integer NOT NULL PRIMARY KEY AUTOINCREMENT, "app_label" varchar(100) NOT NULL, "model" varchar(100) NOT NULL);
CREATE UNIQUE INDEX "django_content_type_app_label_model_76bd3d3b_uniq" ON "django_content_type" ("app_label", "model");
CREATE TABLE IF NOT EXISTS "auth_permission" ("id" integer NOT NULL PRIMARY KEY AUTOINCREMENT, "content_type_id" integer NOT NULL REFERENCES "django_content_type" ("id") DEFERRABLE INITIALLY DEFERRED, "codename" varchar(100) NOT NULL, "name" varchar(255) NOT NULL);
CREATE UNIQUE INDEX "auth_permission_content_type_id_codename_01ab375a_uniq" ON "auth_permission" ("content_type_id", "codename");
CREATE INDEX "auth_permission_content_type_id_2f476e4b" ON "auth_permission" ("content_type_id");
CREATE TABLE IF NOT EXISTS "auth_user" ("id" integer NOT NULL PRIMARY KEY AUTOINCREMENT, "password" varchar(128) NOT NULL, "last_login" datetime NULL, "is_superuser" bool NOT NULL, "username" varchar(150) NOT NULL UNIQUE, "first_name" varchar(30) NOT NULL, "email" varchar(254) NOT NULL, "is_staff" bool NOT NULL, "is_active" bool NOT NULL, "date_joined" datetime NOT NULL, "last_name" varchar(150) NOT NULL);

各アプリの初期(0001_initial.py) 以外のマイグレーションも無事適用されました。

現時点で auth/migrations/ には 10個のマイグレーションがありますが反映されているようです。例えば auth_user.last_name の varchar length が 30 -> 150 になっています。

逆に --fake で適用してしまうと..

--fake の適用
スキーマの状態

$ ./manage.py migrate --fake
Operations to perform:
  Apply all migrations: admin, auth, contenttypes, products, sales, sessions
Running migrations:
  Applying contenttypes.0001_initial... FAKED
  Applying auth.0001_initial... FAKED
  Applying admin.0001_initial... FAKED
  Applying admin.0002_logentry_remove_auto_add... FAKED
  Applying admin.0003_logentry_add_action_flag_choices... FAKED
  Applying contenttypes.0002_remove_content_type_name... FAKED
  Applying auth.0002_alter_permission_name_max_length... FAKED
  Applying auth.0003_alter_user_email_max_length... FAKED
  Applying auth.0004_alter_user_username_opts... FAKED
  Applying auth.0005_alter_user_last_login_null... FAKED
  Applying auth.0006_require_contenttypes_0002... FAKED
  Applying auth.0007_alter_validators_add_error_messages... FAKED
  Applying auth.0008_alter_user_username_max_length... FAKED
  Applying auth.0009_alter_user_last_name_max_length... FAKED
  Applying products.0001_initial... FAKED
  Applying sales.0001_initial... FAKED
  Applying sessions.0001_initial... FAKED

sqlite> .schema
CREATE TABLE IF NOT EXISTS "django_admin_log" (
    "id" integer NOT NULL PRIMARY KEY,
    "action_time" datetime NOT NULL,
    "user_id" integer NOT NULL,
    "content_type_id" integer,
    "object_id" text,
    "object_repr" varchar(200) NOT NULL,
    "action_flag" smallint unsigned NOT NULL,
    "change_message" text NOT NULL
);
CREATE TABLE IF NOT EXISTS "auth_permission" (
    "id" integer NOT NULL PRIMARY KEY,
    "name" varchar(50) NOT NULL,
    "content_type_id" integer NOT NULL,
    "codename" varchar(100) NOT NULL,
    UNIQUE ("content_type_id", "codename")
);
CREATE TABLE IF NOT EXISTS "auth_group_permissions" (
    "id" integer NOT NULL PRIMARY KEY,
    "group_id" integer NOT NULL,
    "permission_id" integer NOT NULL REFERENCES "auth_permission" ("id"),
    UNIQUE ("group_id", "permission_id")
);
CREATE TABLE IF NOT EXISTS "auth_group" (
    "id" integer NOT NULL PRIMARY KEY,
    "name" varchar(80) NOT NULL UNIQUE
);
CREATE TABLE IF NOT EXISTS "auth_user_groups" (
    "id" integer NOT NULL PRIMARY KEY,
    "user_id" integer NOT NULL,
    "group_id" integer NOT NULL REFERENCES "auth_group" ("id"),
    UNIQUE ("user_id", "group_id")
);
CREATE TABLE IF NOT EXISTS "auth_user_user_permissions" (
    "id" integer NOT NULL PRIMARY KEY,
    "user_id" integer NOT NULL,
    "permission_id" integer NOT NULL REFERENCES "auth_permission" ("id"),
    UNIQUE ("user_id", "permission_id")
);
CREATE TABLE IF NOT EXISTS "auth_user" (
    "id" integer NOT NULL PRIMARY KEY,
    "password" varchar(128) NOT NULL,
    "last_login" datetime NOT NULL,
    "is_superuser" bool NOT NULL,
    "username" varchar(30) NOT NULL UNIQUE,
    "first_name" varchar(30) NOT NULL,
    "last_name" varchar(30) NOT NULL,
    "email" varchar(75) NOT NULL,
    "is_staff" bool NOT NULL,
    "is_active" bool NOT NULL,
    "date_joined" datetime NOT NULL
);
CREATE TABLE IF NOT EXISTS "django_content_type" (
    "id" integer NOT NULL PRIMARY KEY,
    "name" varchar(100) NOT NULL,
    "app_label" varchar(100) NOT NULL,
    "model" varchar(100) NOT NULL,
    UNIQUE ("app_label", "model")
);
CREATE TABLE IF NOT EXISTS "django_session" (
    "session_key" varchar(40) NOT NULL PRIMARY KEY,
    "session_data" text NOT NULL,
    "expire_date" datetime NOT NULL
);
CREATE TABLE IF NOT EXISTS "products_category" (
    "id" integer NOT NULL PRIMARY KEY,
    "name" varchar(30) NOT NULL,
    "created_at" datetime NOT NULL
);
CREATE TABLE IF NOT EXISTS "products_product" (
    "id" integer NOT NULL PRIMARY KEY,
    "name" varchar(255) NOT NULL,
    "category_id" integer NOT NULL REFERENCES "products_category" ("id"),
    "created_at" datetime NOT NULL,
    "updated_at" datetime NOT NULL,
    "deleted_at" datetime
);
CREATE TABLE IF NOT EXISTS "products_price" (
    "id" integer NOT NULL PRIMARY KEY,
    "price" integer NOT NULL,
    "product_id" integer NOT NULL REFERENCES "products_product" ("id"),
    "effective_date_start" datetime,
    "effective_date_end" datetime
);
CREATE TABLE IF NOT EXISTS "sales_sales" (
    "id" integer NOT NULL PRIMARY KEY,
    "product_id" integer NOT NULL REFERENCES "products_product" ("id"),
    "sold_at" datetime NOT NULL
);
CREATE TABLE IF NOT EXISTS "sales_summary" (
    "id" integer NOT NULL PRIMARY KEY,
    "date" date NOT NULL,
    "total_sales" integer NOT NULL,
    "total_price" integer NOT NULL,
    "unique_user" integer NOT NULL
);
CREATE INDEX "django_admin_log_6340c63c" ON "django_admin_log" ("user_id");
CREATE INDEX "django_admin_log_37ef4eb4" ON "django_admin_log" ("content_type_id");
CREATE INDEX "auth_permission_37ef4eb4" ON "auth_permission" ("content_type_id");
CREATE INDEX "auth_group_permissions_5f412f9a" ON "auth_group_permissions" ("group_id");
CREATE INDEX "auth_group_permissions_83d7f98b" ON "auth_group_permissions" ("permission_id");
CREATE INDEX "auth_user_groups_6340c63c" ON "auth_user_groups" ("user_id");
CREATE INDEX "auth_user_groups_5f412f9a" ON "auth_user_groups" ("group_id");
CREATE INDEX "auth_user_user_permissions_6340c63c" ON "auth_user_user_permissions" ("user_id");
CREATE INDEX "auth_user_user_permissions_83d7f98b" ON "auth_user_user_permissions" ("permission_id");
CREATE INDEX "django_session_b7b81f0c" ON "django_session" ("expire_date");
CREATE INDEX "products_product_6f33f001" ON "products_product" ("category_id");
CREATE INDEX "products_price_7f1b40ad" ON "products_price" ("product_id");
CREATE INDEX "sales_sales_7f1b40ad" ON "sales_sales" ("product_id");
CREATE TABLE IF NOT EXISTS "django_migrations" ("id" integer NOT NULL PRIMARY KEY AUTOINCREMENT, "app" varchar(255) NOT NULL, "name" varchar(255) NOT NULL, "applied" datetime NOT NULL);
CREATE TABLE sqlite_sequence(name,seq);

適用されるべきマイグレーションまでフェイク適用してしまったようです。

--fake-initial と --fake の使い分けには注意しましょうね。

info

今回はシステムで使っているテーブルだけに恩恵がありましたが今後 products, sales アプリにもマイグレーションが追加され、自分以外のチームメンバーがそのマイグレーションを適用するときも、 --fake-initial は役に立ちます。

😇 NULLが許可されていないフィールドを追加

nullが許可されていないフィールドを追加しようとすると以下のような入力を求められることがあります。

You are trying to add a non-nullable field 'code' to category without a default; we can't do that (the database needs something to populate existing rows).
Please select a fix:
 1) Provide a one-off default now (will be set on all existing rows with a null value for this column)
 2) Quit, and let me add a default in models.py
Select an option:

これは null が許可されていない上、デフォルト値も指定されていないため、すでにレコード (rows) がある場合に補完する値を Django が判断できないので指示を求められています。

それぞれ

1) 既存レコードに割り当てるデフォルト値を対話的に指定する
2) マイグレーションファイルを作るのを中断する (models.py に直接デフォルト値を指定してやりなおしてね)

と言った感じですね。

1 を選ぶ場合、フィールドの方に沿った値で適切なものを指定すればよいです。

また、値としてコーラブルなオブジェクト (例えば django.utils.timezone) を指定すると、実行時の返却値がデフォルト値となります。

warning

これらのデフォルト値はレコードごとに設定することはできず、画一的に同じ値が設定されます。
別カラムの値を元にフィールドの値を設定したい場合は一度 nullable なフィールドとして定義した後、データマイグレーション(後述) を行い、 nullable (null=False) を指定すればよいでしょう。

では、実際に以下のようなカテゴリレコードがあるという状況でやってみます。

insert into products_category(id, name) values
  (1, 'alpaca'),
  (2, 'dog')
;

select * from products_category;
1|alpaca
2|dog

ではマイグレーションを作って適用してみます。デフォルト値は timezone.now にします。

$ ./manage.py makemigrations products
You are trying to add a non-nullable field 'created_at' to category without a default; we can't do that (the database needs something to populate existing rows).
Please select a fix:
 1) Provide a one-off default now (will be set on all existing rows with a null value for this column)
 2) Quit, and let me add a default in models.py
Select an option: 1
Please enter the default value now, as valid Python
The datetime and django.utils.timezone modules are available, so you can do e.g. timezone.now
Type 'exit' to exit this prompt
>>> timezone.now
Migrations for 'products':
  products/migrations/0002_category_created_at.py
    - Add field created_at to category

$ ./manage.py migrate products 0002
Operations to perform:
  Target specific migration: 0002_category_created_at, from products
Running migrations:
  Applying products.0002_category_created_at... OK

フィールドが追加され、デフォルト値も格納されたようです。

sqlite> .schema products_category
CREATE TABLE "products_category" (
  "id" integer NOT NULL PRIMARY KEY AUTOINCREMENT,
  "name" varchar(30) NOT NULL,
  "created_at" datetime NOT NULL
);

sqlite> select * from products_category ;
1|alpaca|2018-12-05 09:47:37.577821
2|dog|2018-12-05 09:47:37.577821

😩 マイグレーションを取り消す

基礎編#migrate でも説明しましたが、適用済マイグレーションを指定するとそれより一つ後のマイグレーションまで逆適用つまり、取り消しが行われます。

0001 (先頭) まで取り消したい場合は zero を指定します。

--fake と併用すると履歴だけを消せます。

products/migrations/ 配下のマイグレーションをすべて適用した状態で

sqlite> select id, app, name from django_migrations;
1|products|0001_initial
2|products|0002_product_deleted_at

sqlite> .table
django_migrations  products_category  products_price     products_product

逆適用した結果を見てみましょう

./manage.py migrate products zero
./manage.py migrate products zero --fake

Operations to perform:
  Unapply all migrations: products
Running migrations:
  Rendering model states... DONE
  Unapplying products.0002_product_deleted_at... OK
  Unapplying products.0001_initial... OK

Operations to perform:
  Unapply all migrations: products
Running migrations:
  Rendering model states... DONE
  Unapplying products.0002_product_deleted_at... FAKED
  Unapplying products.0001_initial... FAKED

sqlite> select id, app, name from django_migrations;
-- products のテーブルは全部消えてる
sqlite> .table
django_migrations

sqlite> select id, app, name from django_migrations;
-- テーブルは消えない！
sqlite> .table
django_migrations  products_category  products_price     products_product

😎 データマイグレーション

既存レコードの整理、初期レコードの追加、フィールドの変更によってスキーマではなくレコードを操作したくなることもあります。

これを行うのが前述した RunSQL や RunPython です。

RunSQL

RunSQL は単純に第一引数で与えた生SQL (DML, 例えば INSERT, UPDATE, DELETE 文 ) を実行するだけです。

第二引数は逆適用の SQLを指定します。省略できます。形式は第一引数と同じです。

まず、空のマイグレーションファイルを用意します.

$ ./manage.py makemigrations products --empty --name='manual'
Migrations for 'products':
  products/migrations/0002_manual.py

マイグレーションファイルはこんな感じになっております

第一引数と第二引数の形式は同じと言いましたが、いきなり違っていますね..

実は RunSQL は引数として文字列を受け取るとそのまま解釈して実行し、タプルのリストとして受け取ると、タプルの中をパラメータとして SQL を組み立て、リストの要素数回実行します。

では順適用と逆適用をしてみましょう。

./manage.py migrate products 0002
結果

$ ./manage.py migrate products 0002
Operations to perform:
  Apply all migrations: products
Running migrations:
  Applying products.0002_manual... OK

sqlite> select * from products_category ;
1|a
2|b
3|c
4|d
5|e
6|f

./manage.py migrate products 0001
結果

$ ./manage.py migrate products 0001
Operations to perform:
  Target specific migration: 0001_initial, from products
Running migrations:
  Rendering model states... DONE
  Unapplying products.0002_manual... OK

sqlite> select * from products_category ;
-- なし

逆適用もできました。

info

django.core.exceptions.ImproperlyConfigured: The sqlparse package is required if you don't split your SQL statements manually. と出た場合は sqlparse をインストールしましょう
Running a .sql file after migrations in django - Stack Overflow
第二引数 (reverse_sql) を指定せずに逆適用をしようとすると django.db.migrations.exceptions.IrreversibleError が発生します。

RunSQL 中で DDL (CREATE TABLE, ALTER 文など) を実行することはあまりおすすめできません。

これらの操作内でスキーママイグレーションが行われても Django は認識できないのです。

どうしても手動で DDL を実行する場合、 state_operations 引数に Django に認識してほしい Operation をリスト形式 (operations 属性と同じ) で指定します。 state_operations 属性は、実際にDBには適用しないけどDjangoには適用したことにするというものです。

少しわかりにくいかもしれないので不整合が起こる例をあげます。

RunSQL で DROP TABLE products_price を指定したマイグレーションを実行
- products_price テーブルが消える
- Django は products_price テーブルが消えたことを知らない
models.py からも Price モデルを削除し makemigrations する
- Django は Price モデルを削除するための Operation (DeleteModel) を含むマイグレーションが自動生成される
2 で作成したマイグレーションを実行
- products_price を削除しようとするが既に削除されているためエラーが発生する (不整合)

上記の場合は下記のように指定すればOKです。

operations = [
    migrations.RunSQL("DROP TABLE products_price", state_operations=[
        migrations.DeleteModel(name='Price'),
    ]),
]

既におわかりかもしれませんが DROP TABLE という生SQLを実行されたとき、 Djangoマイグレーションにおいて同等の DeleteModel が実行されたことにするという意味ですね。

しかしこんなことをやるのは冗長です。「どうしても」というときを除きできるだけ Django に任せましょう

RunPython

先ほどと同様に空のマイグレーションファイルを作成します。

$ ./manage.py makemigrations products --empty --name='manual'
Migrations for 'products':
  products/migrations/0003_manual.py

今回はカテゴリを全部大文字にするようなものを考えてみました。 (ただしquerysetでやるようなメリットはない..)

from django.db import migrations
from django.db.models import Func, F


def set_categories_uppercase(apps, schema_editor):
    Category = apps.get_model("products", "Category")
    Category.objects.all().update(
        name=Func(F('name'), function='UPPER')
    )

def set_categories_lowercase(apps, schema_editor):
    Category = apps.get_model("products", "Category")
    Category.objects.all().update(
        name=Func(F('name'), function='LOWER')
    )

class Migration(migrations.Migration):

    dependencies = [
        ('products', '0002_manual'),
    ]

    operations = [
        migrations.RunPython(set_categories_uppercase, set_categories_lowercase)
    ]

./manage.py migrate products 0003
結果

$ ./manage.py migrate products 0003
Operations to perform:
  Apply all migrations: products
Running migrations:
  Applying products.0003_manual... OK

sqlite> select * from products_category ;
7|A
8|B
9|C
10|D
11|E
12|F

./manage.py migrate products 0002
結果

$ ./manage.py migrate products 0002
Operations to perform:
  Target specific migration: 0002_manual, from products
Running migrations:
  Rendering model states... DONE
  Unapplying products.0003_manual... OK

sqlite> select * from products_category ;
7|a
8|b
9|c
10|d
11|e
12|f

warning

これはメリットでもあり、デメリットでもあるんですが、 migrations.RunPython 関数内でレコードに変更が生じても登録されているシグナルは発火しません。
後処理などをシグナルで行っている場合、マイグレーションで同様の処理を実施してあげる必要があります。

info

Django では初期データの投入方法として fixture が推奨されてきましたが、 Django 1.8 でデータマイグレーションが推奨されるようになりました。
- Providing initial data for models | Django documentation | Django 1.8
- Providing initial data for models | Django documentation | Django 2.1
ただ、マイグレーションによって自動投入されてほしくないようなデータは fixture を使う想定なんだと思います。
とはいえ、JSON で表すのに適していない大量データや、別のデータに依存しているデータ、規則性のあるデータはマイグレーションで作ったほうが良いかもしれません。
状況に応じて柔軟に使い分けていきましょう。

😯 Operation クラスをカスタマイズする

Operation クラスを継承してカスタムした操作を作成できます。

私の想像力が乏しいため、カスタマイズしないとできないような例が思い浮かばなかったので、カテゴリを追加するような操作を自分で作ってみましょう。 (RunSQL や RunPython でもできます)

前回と同様、空のマイグレーションファイルを用意します.

$ ./manage.py makemigrations products --empty --name='manual'
Migrations for 'products':
  products/migrations/0002_manual.py

from django.db import migrations
from django.db.migrations.operations.base import Operation


class CreateCategory(Operation):
    reversible = True

    def __init__(self, name):
        self.name = name

    def state_forwards(self, app_label, state):
        pass

    def database_forwards(self, app_label, schema_editor, from_state, to_state):
        schema_editor.execute("INSERT INTO products_category (name) VALUES (%s);", (self.name,))

    def database_backwards(self, app_label, schema_editor, from_state, to_state):
        schema_editor.execute("DELETE FROM products_category WHERE name=%s;", (self.name,))

    def describe(self):
        return "Creates category %s" % self.name


class Migration(migrations.Migration):

    dependencies = [
        ('products', '0001_initial'),
    ]

    operations = [
        CreateCategory('alpaca'),
        CreateCategory('dog'),
    ]

重要なのは以下のメソッドです。

database_forwards: 実行する操作を記述
database_backwards: 実行した操作を打ち消すための操作を記述
reversible: True であれば backwards 可能

今回のカスタムオペレーションを使うためには operations 属性に指定するだけです。

では適用してみます。

./manage.py migrate products 0002
結果

$ ./manage.py migrate products
Operations to perform:
  Apply all migrations: products
Running migrations:
  Applying products.0001_initial... OK
  Applying products.0002_manual... OK

sqlite> select * from products_category ;
1|alpaca
2|dog

つづいて逆適用。

./manage.py migrate products 0001
結果

$ ./manage.py migrate products 0001
Operations to perform:
  Target specific migration: 0001_initial, from products
Running migrations:
  Rendering model states... DONE
  Unapplying products.0002_manual... OK

sqlite> select * from products_category ;
-- なし

うまく動いたみたいです。

😠 既存データに合わないスキーママイグレーション

makemigrations コマンドは DBの状態を考慮せずにマイグレーションファイルを作ると言いました。

そのため、スキーマ的にはマイグレーション可能でも実際に適用してみると、既存データが変更後の 型 や 制約 に合わずにマイグレーションが失敗することがあります。

色んなパターンがあるので網羅は難しいんですが、今回は型の変更について説明します。

以下のシナリオでやってみます。

Category モデルの id列を UUIDField から Autofield (integer) フィールドに変更する
- id 列は主キー
- キャスト不可能
created の順に連番を振りなおす
Product.category は Category.id を外部参照している
- レコードは 1件以上存在する

既にテーブルは作成されている

作成
適用

./manage.py makemigrations products
Migrations for 'products':
  products/migrations/0001_initial.py
    - Create model Category
    - Create model Price
    - Create model Product
    - Add field product to price

$ ./manage.py migrate products 0001
Operations to perform:
  Apply all migrations: products
Running migrations:
  Applying products.0001_initial... OK

既に次のようなレコードが入っている

insert into products_category(id, name, created_at) values
  ('5fe87b34-1d84-4dd2-bfdd-4c9d275bc5a2', 'alpaca', '2018-01-01'),
  ('c5a63139-3470-4e07-9668-d2c9edc478bd', 'dog', '2018-01-02'),
  ('4ca1bcbd-64b2-4f13-a445-6b096ee655aa', 'cat', '2018-01-03'),
  ('e12db291-875e-4a2b-aedd-5423fd8eb18c', 'capibara', '2018-01-01')
;

insert into products_product(name, category_id, created_at, updated_at) values
  ('アルパカの置物', '5fe87b34-1d84-4dd2-bfdd-4c9d275bc5a2', '2018-02-01', '2018-02-01')
;

この状態でマイグレーションを普通に適用しようとすると次のようなエラーになります。

$ ./manage.py migrate
Operations to perform:
  Apply all migrations: accounts, admin, auth, contenttypes, products, sessions
Running migrations:
  Applying products.0003_uuid_to_integer...Traceback (most recent call last):
  File "/venv/lib/python3.7/site-packages/django/db/backends/utils.py", line 85, in _execute
    return self.cursor.execute(sql, params)
  File "/venv/lib/python3.7/site-packages/django/db/backends/sqlite3/base.py", line 296, in execute
    return Database.Cursor.execute(self, query, params)
sqlite3.IntegrityError: datatype mismatch

では、情報が失われないように気をつけながらデータとスキーマを変更していきます。

Category モデルに入れ替え用のフィールドを定義

id2 = models.IntegerField(default=0)
- 作成
- マイグレーションファイル

$ ./manage.py makemigrations products --name="id2"
Migrations for 'products':
  products/migrations/0002_id2.py
    - Add field id2 to category

入れ替え要のフィールドに一意な連番を振る

空のマイグレーションファイルを作る

./manage.py makemigrations products --empty --name="put_serial_number"

連番で更新するような Operation (RunSQL) をマイグレーションに追加する

今使ってる SQLite3 のバージョンではWindow関数が使えないのでこんな感じで..

作成
マイグレーションファイル

./manage.py makemigrations products --empty --name="put_serial_number"
Migrations for 'products':
  products/migrations/0003_put_serial_number.py

Category を外部参照しているモデルに入れ替え用のフィールドを追加

今回は Product モデルのみ
- category_id2 = models.IntegerField(default=0)
  - 追加するフィールドは Category.id2 の型と一致すること

作成
マイグレーションファイル

$ ./manage.py makemigrations products --name="category_id2"
Migrations for 'products':
  products/migrations/0004_category_id2.py
    - Add field category_id2 to product

Category を外部参照しているモデルの入れ替え用フィールドに現在の主キーに紐づく連番を格納する

今回は Product モデルのみ
- 空のマイグレーションファイルを作る
- Product.category_id に紐づく Category.id2 を Product.category_id2 に入れるような UPDATE 文を実行する Operation (RunSQL) を空マイグレーションに追加する
- 変更するのが主キーでない場合は不要

作成
マイグレーションファイル

$ ./manage.py makemigrations products --empty --name="put_new_pk"
Migrations for 'products':
  products/migrations/0005_put_new_pk.py

Category を外部参照しているフィールドを削除する

今回は Product モデルのみ
- # category = models.ForeignKey(Category, on_delete=models.CASCADE)
  - あとから復活させるためコメントアウトに留める

作成
マイグレーションファイル

$ ./manage.py makemigrations products --name="del_category_id"
Migrations for 'products':
  products/migrations/0006_del_category_id.py
    - Remove field category from product

Category の入れ替え用フィールドを主キーにする

id2 フィールドを AutoField に変更する (主キーの指定も必要)
- id フィールドを削除する
  - # id = models.UUIDField(primary_key=True, default=uuid.uuid4)
    - 今回は差分をわかりやすくするためにコメントアウト

作成
マイグレーションファイル

$ ./manage.py makemigrations products --name="id2_primary_key"
Migrations for 'products':
  products/migrations/0007_id2_primary_key.py
    - Remove field id from category
    - Alter field id2 on category

Category の入れ替え用フィールドを id にする

id2 のフィールド名を id に変更

作成
マイグレーションファイル

$ ./manage.py makemigrations products --name="id2_to_id"
Did you rename category.id2 to category.id (a AutoField)? [y/N] y
Migrations for 'products':
  products/migrations/0008_id2_to_id.py
    - Rename field id2 on category to id

Product.category_id2 から Product.category_id に変更

Category を外部参照しているモデルの入れ替え用フィールドをリネームする
- Product.category_id2 のフィールド名を category_id に変更する
  - category_id2 = models.IntegerField(default=0)

作成
マイグレーションファイル

$ ./manage.py makemigrations products --name="category_id2_to_category_id"
Did you rename product.category_id2 to product.category_id (a IntegerField)? [y/N] y
Migrations for 'products':
  products/migrations/0009_category_id2_to_category_id.py
    - Rename field category_id2 on product to category_id

Product.category_id を ForeignKey に変更する

Product.category_id のフィールドを削除
- # category_id = models.IntegerField(default=0)
Product.category を ForeignKey で定義する
- category = models.ForeignKey(Category, on_delete=models.CASCADE)
  - 先程コメントアウトしたものを外すだけでよい
自動で ForeignKey にするのは無理なので、手動で空のマイグレーションファイルを作る
- ./manage.py makemigrations products --empty --name="category_id_to_foreignkey"
- migrations.AlterField を使ってフィールドを変更

作成
マイグレーションファイル

$ ./manage.py makemigrations products --empty --name="category_id_to_foreignkey"
Migrations for 'products':
  products/migrations/0010_category_id_to_foreignkey.py

実行する

これを実行すると

$ ./manage.py migrate products
Operations to perform:
  Apply all migrations: products
Running migrations:
  Applying products.0002_id2... OK
  Applying products.0003_put_serial_number... OK
  Applying products.0004_category_id2... OK
  Applying products.0005_put_new_pk... OK
  Applying products.0006_del_category_id... OK
  Applying products.0007_id2_primary_key... OK
  Applying products.0008_id2_to_id... OK
  Applying products.0009_category_id2_to_category_id... OK
  Applying products.0010_category_id_to_foreignkey... OK

migrate は無事終わったようですが、

さて、どうなったかな。

Before
After

sqlite> select * from products_category;
5fe87b34-1d84-4dd2-bfdd-4c9d275bc5a2|alpaca|2018-01-01
c5a63139-3470-4e07-9668-d2c9edc478bd|dog|2018-01-02
4ca1bcbd-64b2-4f13-a445-6b096ee655aa|cat|2018-01-03
e12db291-875e-4a2b-aedd-5423fd8eb18c|capibara|2018-01-01

sqlite> select * from products_product;
1|アルパカの置物|2018-02-01|2018-02-01||5fe87b34-1d84-4dd2-bfdd-4c9d275bc5a2

sqlite> select * from products_category;
alpaca|2018-01-01|1
capibara|2018-01-01|2
dog|2018-01-02|3
cat|2018-01-03|4

sqlite> select * from products_product;
1|アルパカの置物|2018-02-01|2018-02-01|1

無事にデータ移行できたようです。

warning

別の口から処理を受け付けていると連番がユニークにならずマイグレーションが失敗する可能性があります。
マイグレーションを実行するときは、できるだけメンテナンス時間などを設けて外部と遮断した上で適用することをおすすめします。

note

キャスト可能な型の場合はそのまま格納可能です。
AutoField (integer) から UUIDField に変えた場合、 SQLite3では UUID は char 型なので単純に文字列キャストされて格納されます。

sqlite> .schema products_category
CREATE TABLE IF NOT EXISTS "products_category" ("name" varchar(30) NOT NULL, "id" char(32) NOT NULL PRIMARY KEY);

sqlite> select * from products_category ;
test|1

PostgreSQL のように異なる型として認識される場合は先程と同様にデータを調整してあげる必要があります。

今更ですが、主キーをキャスト不可能な型に変更するとか正気の沙汰ではないので普通はやめましょう。

😌 同じ親を持つマイグレーション

あなたが一人で開発をしていて、一つのブランチ(Gitなど) で作業している場合、このようなケースに遭遇することはめったにないと思いますが、複数人で開発していると同じアプリ内の同じ親を参照するマイグレーションができあがってしまうことが稀によくあります。

Mercurial (VCS) で言うところのいわゆるマルチプルヘッド (双頭) と呼ばれる、先端が二又以上に分かれた状態です。

Django 的にもこの状態は好ましくありません。

実際に試してみましょう。今回は accounts アプリの 0004, 0005 がいずれも 0003 を参照しているという状態、つまり末端が 2又に分かれています。

info

本来、上記のように連続した番号で参照する親が重複するということはまず発生しませんが、わかりやすさのためこのようにしています。

この状態でマイグレーションを適用するとエラーが発生します。

error

CommandError: Conflicting migrations detected; multiple leaf nodes in the migration graph: (0005_dummy, 0004_dummy in accounts). To fix them run 'python manage.py makemigrations --merge'

エラーメッセージでも言っている通りこれらのファイルを一つに束ねるのが makemigrations の --merge オプションです。

$ ./manage.py makemigrations accounts --merge --name='merged'
Merging accounts
  Branch 0004_dummy
  Branch 0005_dummy

Merging will only work if the operations printed above do not conflict
with each other (working on different fields or models)
Do you want to merge these migration branches? [y/N] y

Created new merge migration apps-multiple-heads/accounts/migrations/0006_merged.py

これにより以下のような 0006 が作られ、今回は無事適用できたようです。

マイグレーションファイル
適用

$ ./manage.py migrate accounts
Operations to perform:
  Apply all migrations: accounts
Running migrations:
  Applying accounts.0001_initial... OK
  Applying accounts.0002_dummy... OK
  Applying accounts.0003_dummy... OK
  Applying accounts.0005_dummy... OK
  Applying accounts.0004_dummy... OK
  Applying accounts.0006_merged... OK

このことから先端さえ収束していれば Django 的にはOKということになります。

flowchart TB
  0001-->0002;
  0002-->0003;
  0003-->0004;
  0003-->0005;

flowchart TB
  0001-->0002;
  0002-->0003;
  0003-->0004;
  0003-->0005;
  0004-->0006;
  0005-->0006;

上記の図でいうと

0004, 0005 までで終わっている場合はアウトですが、 0006 で束ねている状態はセーフなのです。

info

--merge は先端が分岐してしまったマイグレーションを一つに束ねるだけのオプションであり、 squashmigrations のように複数のマイグレーションを意味のある１つのマイグレーションに統合する機能では ありません
その心はおそらく、実行順の制御のためではなく、次回マイグレーションを自動生成する場合に終端がわからないと Dependencies に指定するマイグレーションが一意に特定できないからだと思います。
分岐している部分のマイグレーション(0004, 0005)は番号の順番とは関係なく適用されることがわかります。
重複したマイグレーションの順番を制御したい場合、マイグレーションファイルの依存関係を自分で調整してあげましょう。 (ローカルDBへ既に適用されていることがほとんどなので、未適用のDBとは順番のズレが生じる可能性があります)

😱 マイグレーションが10000回を突破する

番号が 0パディングの 4桁なので 10000 を超えても大丈夫なのかなーと心配する僕みたいなひねくれた方がいるかもしれません。

コードを見てもマイグレーション数を制限している部分はありませんが、一応検証してみました。

結論から言うと特に限界はなく、 10000超えても作成、適用はできます。

$ ./manage.py makemigrations accounts --empty --name='dummy'
Migrations for 'accounts':
  accounts/migrations/10000_dummy.py

$ ./manage.py makemigrations accounts --empty --name='dummy'
Migrations for 'accounts':
  accounts/migrations/10001_dummy.py

$ ./manage.py migrate accounts
Operations to perform:
  Apply all migrations: accounts
Running migrations:
  Applying accounts.0001_initial... OK
  Applying accounts.9999_dummy... OK
  Applying accounts.10000_dummy... OK
  Applying accounts.10001_dummy... OK

warning

今回はファイル名を適当に調整して 9999 以降のマイグレーションを作りましたが、実際に 9999 件ある状態で試したところ makemigrations だけで時間(5分くらい)がかかってエラーが出ます。
error
- RuntimeWarning: Maximum recursion depth exceeded while generating migration graph, falling back to iterative approach. If you're experiencing performance issues, consider squashing migrations as described at https://docs.djangoproject.com/en/dev/topics/migrations/#squashing-migrations.
ある程度溜まったら squashmigrations するのがおすすめです。

😅 複数のフィールドをリネームする

一つのモデルにおいてフィールドの追加と削除を同時に検知した場合、 Django はフィールドがリネームされたと推測し、対話的に紐づけてよいか確認してきます。賢いですね。

一つの場合は y (yes) を選んで終わりですがこれが複数あった場合について考えてみましょう。

特に難しいわけではないですが、初学者にとっては戸惑うポイントかも知れないので一応やっておきます。

たとえば、 Price というモデルのフィールドを同時に以下のように変更し makemigrations をします。

effective_date_from -> effective_date_start
effective_date_to -> effective_date_end

するとすべての組み合わせについてヒモ付が正しいか確認してくるので、 y/N で教えてあげます。

$ ./manage.py makemigrations products --name='rename_fields'
Did you rename price.effective_date_from to price.effective_date_end (a DateTimeField)? [y/N] N
Did you rename price.effective_date_to to price.effective_date_end (a DateTimeField)? [y/N] y
Did you rename price.effective_date_from to price.effective_date_start (a DateTimeField)? [y/N] y
Migrations for 'products':
  products/migrations/0002_rename_fields.py
    - Rename field effective_date_to on price to effective_date_end
    - Rename field effective_date_from on price to effective_date_start

info

解説
- Did you rename price.effective_date_from to price.effective_date_end (a DateTimeField)? [y/N] n
  - effective_date_from から effective_date_end にリネームするけど正しい？と聞いてくるので No
  - No を選択するとこのリネームはスキップされます
- Did you rename price.effective_date_to to price.effective_date_end (a DateTimeField)? [y/N] y
  - effective_date_to から effective_date_end にリネームするけど正しい？と聞いてくるので Yes
- Did you rename price.effective_date_from to price.effective_date_start (a DateTimeField)? [y/N] y
  - effective_date_from から effective_date_start にリネームするけど正しい？と聞いてくるので Yes

でこんな感じのマイグレーションが作られます。

適用してみます。

マイグレーションファイル
適用

$ ./manage.py migrate products
Operations to perform:
  Apply all migrations: products
Running migrations:
  Applying products.0001_initial... OK
  Applying products.0002_rename_fields... OK

適用後に sales_price のスキーマを比較してみましょう

Before
After

sqlite> .schema products_price
CREATE TABLE IF NOT EXISTS "products_price" (
  "id" integer NOT NULL PRIMARY KEY AUTOINCREMENT,
  "price" integer NOT NULL,
  "effective_date_from" datetime NULL,
  "effective_date_to" datetime NULL,
  "product_id" integer NOT NULL REFERENCES "products_product" ("id") DEFERRABLE INITIALLY DEFERRED);
CREATE INDEX "products_price_product_id_8481dedb" ON "products_price" ("product_id");

sqlite> .schema products_price
CREATE TABLE IF NOT EXISTS "products_price" (
  "id" integer NOT NULL PRIMARY KEY AUTOINCREMENT,
  "price" integer NOT NULL,
  "effective_date_end" datetime NULL,
  "product_id" integer NOT NULL REFERENCES "products_product" ("id") DEFERRABLE INITIALLY DEFERRED,
  "effective_date_start" datetime NULL);
CREATE INDEX "products_price_product_id_8481dedb" ON "products_price" ("product_id");

ちゃんとリネームされているようです。

warning

対話で紐づけ関係が解決できない場合、「フィールドを一旦削除し、新規フィールドを追加する」という挙動になるので注意してください。
本当にフィールドを削除して別のフィールドを追加したいこともあるでしょうから、この挙動が一概に誤りとは言えません。
不安な方は「削除のマイグレーション」と「追加のマイグレーション」を分けて作成するというのも一つの手です。

😶 ビューをモデルとして登録する

VIEW をモデルとして登録したいことがあるかもしれません。 (Django の Viewではないですよ)

単純に同じテーブル名とフィールドを定義すればよいのですが、マイグレーション対象として管理したくないので managed = False を指定します。

これを使ったモデルは次のように定義できます。

class DoubleCategory(models.Model):
    id = models.IntegerField(primary_key=True)
    name = models.CharField(max_length=255)

    class Meta:
        db_table = 'double_category'
        managed = False

特に良い例が思い浮かばなかったので category を 2 つつなげるだけの単純な VIEWを想定します。

作成
適用

$ ./manage.py makemigrations products --name='double_category'
Migrations for 'products':
  products/migrations/0002_double_category.py
    - Create model DoubleCategory

$ ./manage.py migrate products
Operations to perform:
  Apply all migrations: products
Running migrations:
  Applying products.0001_initial... OK
  Applying products.0002_double_category... OK

期待通り、テーブルはできてませんね

sqlite> .schema double_category
-- なし

必要に応じて適当な VIEW を定義します。 (管理されないのでVIEWはあってもなくてもいいです)

sqlite> CREATE VIEW double_category AS SELECT id, name || ' ' || name AS name FROM products_category;
sqlite> INSERT INTO products_category (name) VALUES ('a'), ('b'), ('c');
sqlite> select * from double_category ;
1|a a
2|b b
3|c c

最後にインタラクティブシェルから使ってみます。

>>> from products.models import DoubleCategory
>>> DoubleCategory.objects.values()
<QuerySet [{'id': 1, 'name': 'a a'}, {'id': 2, 'name': 'b b'}, {'id': 3, 'name': 'c c'}]>

はい、できました。

info

今回は VIEW を使う例として managed = False を定義しましたが、他には別のシステムで使っているテーブルを Django から参照したい(ただ、管理はしたくない) という場合も同様に対処できます。

😛 ファクトリで生成した関数をモデルに指定する

Django の makemigrations はモデルの変更を検知してマイグレーションを作成するわけですが、いくつかのフィールドでは関数を引数として受け取れます。

具体的には default や FileField の upload_to ですが、ここにファクトリ関数を指定しようとすると一苦労なのです。

まず、ファクトリ関数(クロージャ機能を用いて関数等のオブジェクトを生成する関数) についてわからない方もいると思うので簡単な例をあげます。 ID (UUID) から自動的にファイルの保存パスを決定するような関数を作成するファクトリを作ります。

以下のようにユーザレコードの ID(UUID) を4桁ずつのディレクトリに区切ったパスを生成する関数を作ってみます。 (この時点ではファクトリではないです)

import os
import unicodedata

def make_user_path(instance, filename):
    prefix = 'user/'
    path = [prefix.strip('/')]
    path += [instance.id.hex[i:i+4] for i in range(0, 32, 4)]
    path += [unicodedata.normalize('NFC', filename)]
    return os.path.join(*path)

これを実行すると期待したようなパスを得られることがわかります。

>>> from accounts.models import User
>>> u = User.objects.create(email='test@example.com', nickname='tester', age=75)
>>> make_user_path(u, 'test.txt')
>>> 'user/64bb/fa2e/36fc/4faa/aa2b/3367/4153/7c9e/test.txt'

このまま upload_to 引数に指定してもよいのですが、同じ生成ルールで他テーブルの添付ファイルも配置したいということになりました。ただ、出力先のディレクトリ (prefix)は任意のものを指定したいのです。

ここでファクトリ関数の出番です。やることは割と単純で先程の関数を別の関数でラップして返却するイメージです。

prefixは外側の関数から渡してあげれば内側の関数でも参照でき、出力された関数では常に prefixが固定されているというわけです。変数を閉じ込めていると表現することもあります。

import os
import unicodedata

def make_path_factory(prefix):
    def make_path(instance, filename):
        path = [prefix.strip('/')]
        path += [instance.id.hex[i:i+4] for i in range(0, 32, 4)]
        path += [unicodedata.normalize('NFC', filename)]
        return os.path.join(*path)
    return make_path

一旦関数を出力してから先ほどと同様に使ってみましょう。今回は avatar に変えてみました。

>>> make_user_path = make_path_factory('avatar')
>>> make_user_path(u, 'test.txt')
'avatar/64bb/fa2e/36fc/4faa/aa2b/3367/4153/7c9e/test.txt'

これですべてのモデルの添付ファイルを別々のディレクトリに出力することができる！

と思ってしまいそうですが、そう簡単には物事は運ばないようです。

試しに、このファクトリをモデルに指定してマイグレーションをしてみましょう。

モデル
適用

import os
import unicodedata

from django.db import models
from django.contrib.auth.models import (
    BaseUserManager, AbstractBaseUser
)

def make_path_factory(prefix):
    def make_path(instance, filename):
        path = [prefix.strip('/')]
        path += [instance.id.hex[i:i+4] for i in range(0, 32, 4)]
        path += [unicodedata.normalize('NFC', filename)]
        return os.path.join(*path)
    return make_path

make_path = make_path_factory('user/')

class User(AbstractBaseUser):
    USERNAME_FIELD = 'email'

    email = models.EmailField(max_length=255, unique=True)
    nickname = models.CharField(max_length=20)
    age = models.IntegerField(null=True)
    file = models.FileField(upload_to=make_path)

./manage.py makemigrations accounts
Migrations for 'accounts':
  accounts/migrations/0001_initial.py
    - Create model User
Traceback (most recent call last):
  File "./manage.py", line 15, in <module>
    execute_from_command_line(sys.argv)
  File "/venv/lib/python3.7/site-packages/django/core/management/__init__.py", line 381, in execute_from_command_line
    utility.execute()
  File "/venv/lib/python3.7/site-packages/django/core/management/__init__.py", line 375, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/venv/lib/python3.7/site-packages/django/core/management/base.py", line 316, in run_from_argv
    self.execute(*args, **cmd_options)
  File "/venv/lib/python3.7/site-packages/django/core/management/base.py", line 353, in execute
    output = self.handle(*args, **options)
  File "/venv/lib/python3.7/site-packages/django/core/management/base.py", line 83, in wrapped
    res = handle_func(*args, **kwargs)
  File "/venv/lib/python3.7/site-packages/django/core/management/commands/makemigrations.py", line 184, in handle
    self.write_migration_files(changes)
  File "/venv/lib/python3.7/site-packages/django/core/management/commands/makemigrations.py", line 222, in write_migration_files
    migration_string = writer.as_string()
  File "/venv/lib/python3.7/site-packages/django/db/migrations/writer.py", line 151, in as_string
    operation_string, operation_imports = OperationWriter(operation).serialize()
  File "/venv/lib/python3.7/site-packages/django/db/migrations/writer.py", line 110, in serialize
    _write(arg_name, arg_value)
  File "/venv/lib/python3.7/site-packages/django/db/migrations/writer.py", line 62, in _write
    arg_string, arg_imports = MigrationWriter.serialize(item)
  File "/venv/lib/python3.7/site-packages/django/db/migrations/writer.py", line 279, in serialize
    return serializer_factory(value).serialize()
  File "/venv/lib/python3.7/site-packages/django/db/migrations/serializer.py", line 37, in serialize
    item_string, item_imports = serializer_factory(item).serialize()
  File "/venv/lib/python3.7/site-packages/django/db/migrations/serializer.py", line 197, in serialize
    return self.serialize_deconstructed(path, args, kwargs)
  File "/venv/lib/python3.7/site-packages/django/db/migrations/serializer.py", line 85, in serialize_deconstructed
    arg_string, arg_imports = serializer_factory(arg).serialize()
  File "/venv/lib/python3.7/site-packages/django/db/migrations/serializer.py", line 157, in serialize
    'Could not find function %s in %s.\n' % (self.value.__name__, module_name)
ValueError: Could not find function make_path in accounts.models.

期待した関数は accounts.models には定義されていないと言われているようです。

関数名を合わせているのになぜでしょうか。実はファクトリで作られた関数名 (Python3 の場合は __qualname__) は make_path_factory.<locals>.make_path] なので名前が合わないようです。

もちろん、これを手動で合わせてあげればいいんですが、こういうメタ情報はできれば自分で触りたくありませんね。

Pythonにはこういった関数から返却された関数にメタ情報を引き継ぐための関数があります。そうです。主にデコレータに使う functools.wraps ですね。

今回は functools.wraps を使ったデコレータとして再定義してあげましょう。 (他にいいやり方がある方は教えてください)

ついでに Group モデルの添付ファイルパスも作れるようにしてみます。

モデル
作成＆適用

$ ./manage.py makemigrations accounts
Migrations for 'accounts':
  accounts/migrations/0001_initial.py
    - Create model User
    - Create model Group

$ ./manage.py migrate accounts
Operations to perform:
  Apply all migrations: accounts
Running migrations:
  Applying accounts.0001_initial... OK

最後にこのモデルを使ってレコードを作って期待通りのパスにファイルが吐かれるか確かめてみます。

レコードを作ってみる
ファイルが配置される

>>> from django.core.files.base import ContentFile
>>> from accounts.models import User, Group

>>> f = ContentFile(b'file content', 'test.txt')

>>> u = User.objects.create(email='test@example.com', nickname='くろのて', age=5, file=f)
>>> u.id
UUID('a1bc0f6c-fc58-4df5-a840-1f589f0a4d57')

>>> g = Group.objects.create(name='test', file=f)
>>> g.id
UUID('15c6ee18-b3b2-4739-8396-9d8f506a568f')

$ ls -R media
group user

media/group:
15c6

media/group/15c6:
ee18

media/group/15c6/ee18:
b3b2

media/group/15c6/ee18/b3b2:
4739

media/group/15c6/ee18/b3b2/4739:
8396

media/group/15c6/ee18/b3b2/4739/8396:
9d8f

media/group/15c6/ee18/b3b2/4739/8396/9d8f:
506a

media/group/15c6/ee18/b3b2/4739/8396/9d8f/506a:
568f

media/group/15c6/ee18/b3b2/4739/8396/9d8f/506a/568f:
test.txt

media/user:
a1bc

media/user/a1bc:
0f6c

media/user/a1bc/0f6c:
fc58

media/user/a1bc/0f6c/fc58:
4df5

media/user/a1bc/0f6c/fc58/4df5:
a840

media/user/a1bc/0f6c/fc58/4df5/a840:
1f58

media/user/a1bc/0f6c/fc58/4df5/a840/1f58:
9f0a

media/user/a1bc/0f6c/fc58/4df5/a840/1f58/9f0a:
4d57

media/user/a1bc/0f6c/fc58/4df5/a840/1f58/9f0a/4d57:
test.txt

計画通り！

😴 複数のデータベースに対してマイグレーションを適用する

案件によっては複数のデータベースを管理していることがあります。

今回は次のような設定にしました。 (該当部分)

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

migrate コマンドの --database オプションで対象となるデータベースを指定するとマイグレーションは対象DBにだけ適用されます。

default
users

$ ./manage.py migrate
Operations to perform:
  Apply all migrations: accounts, admin, auth, contenttypes, products, sales, sessions
Running migrations:
  Applying accounts.0001_initial... OK
  Applying contenttypes.0001_initial... OK
  Applying admin.0001_initial... OK
  Applying admin.0002_logentry_remove_auto_add... OK
  Applying admin.0003_logentry_add_action_flag_choices... OK
  Applying contenttypes.0002_remove_content_type_name... OK
  Applying auth.0001_initial... OK
  Applying auth.0002_alter_permission_name_max_length... OK
  Applying auth.0003_alter_user_email_max_length... OK
  Applying auth.0004_alter_user_username_opts... OK
  Applying auth.0005_alter_user_last_login_null... OK
  Applying auth.0006_require_contenttypes_0002... OK
  Applying auth.0007_alter_validators_add_error_messages... OK
  Applying auth.0008_alter_user_username_max_length... OK
  Applying auth.0009_alter_user_last_name_max_length... OK
  Applying products.0001_initial... OK
  Applying sales.0001_initial... OK
  Applying sessions.0001_initial... OK

$ ./manage.py migrate --database=users
Operations to perform:
  Apply all migrations: accounts, admin, auth, contenttypes, products, sales, sessions
Running migrations:
  Applying accounts.0001_initial... OK
  Applying contenttypes.0001_initial... OK
  Applying admin.0001_initial... OK
  Applying admin.0002_logentry_remove_auto_add... OK
  Applying admin.0003_logentry_add_action_flag_choices... OK
  Applying contenttypes.0002_remove_content_type_name... OK
  Applying auth.0001_initial... OK
  Applying auth.0002_alter_permission_name_max_length... OK
  Applying auth.0003_alter_user_email_max_length... OK
  Applying auth.0004_alter_user_username_opts... OK
  Applying auth.0005_alter_user_last_login_null... OK
  Applying auth.0006_require_contenttypes_0002... OK
  Applying auth.0007_alter_validators_add_error_messages... OK
  Applying auth.0008_alter_user_username_max_length... OK
  Applying auth.0009_alter_user_last_name_max_length... OK
  Applying products.0001_initial... OK
  Applying sales.0001_initial... OK
  Applying sessions.0001_initial... OK

default
users

sqlite> .table
accounts_user           django_content_type     products_product
auth_group              django_migrations       sales_sales
auth_group_permissions  django_session          sales_summary
auth_permission         products_category
django_admin_log        products_price

sqlite> .table
accounts_user           django_content_type     products_product
auth_group              django_migrations       sales_sales
auth_group_permissions  django_session          sales_summary
auth_permission         products_category
django_admin_log        products_price

同じように適用されていますが、せっかくDBを分けているのに全部適用されるのはうれしくないです。NGなケースもあるでしょう。

Django には database router という機能があり、これを使うことで適用DBを透過的に振り分けられます。

今回は accounts/models.py のテーブルは users データベースに作られるようにしてみます。

DBルーター
settings.py (一部)

DATABASE_ROUTERS = ['apps.router.Router']

マイグレーションを制御するには Router クラスの allow_migrate というメソッドにて、適用する / しない を True / False で返却します。
- DB名, アプリ名, モデル名(小文字) が文字列で参照できます。
- None は True と判断され、適用されるようです。
  - ドキュメントでは None の動作は明記されていなかったので、確実な動作を望む場合はもれなく真偽値を返却するようにしましょう。
Router を指すモジュールパスを settings の DATABASE_ROUTER という変数にリスト形式で指定します。

DBをリセットしてもう一度適用してみます。

default
users

sqlite> .tables
auth_group              django_content_type     products_price
auth_group_permissions  django_migrations       products_product
auth_permission         django_session          sales_sales
django_admin_log        products_category       sales_summary

sqlite> .tables
accounts_user      django_migrations

期待通り accounts/models.py のテーブルは users DBにのみ存在していますね。

info

今回は扱いませんでしたが、 Database router は他にもメソッドがあります。
気になる方は調べてみてください。

🤗 終わりに

長かったケーススタディ編も以上で終了です。

気になる方はリポジトリをクローンして手元で確かめてみてください。

もしかしたらこの記事を見ている人の中には現在マイグレーションのトラブルに見舞われている人もいるかもしれません。

どの状態を 正 するか
現在どこまで適用されているか (showmigrations)
何が原因で問題が発生しているのか
- 何を適用しようとしてどのようなエラーが発生したのか (エラーをよく読む)
- 適用できた環境と違う点はなにか (差分の比較)
失われたデータはあるか
- バックアップから復元可能か

これらの分析を行った上で落ち着いて対応計画を立てましょう。今の私達なら可能なはずです 😼

Django マイグレーション完全に理解した (ケーススタディ編) 🍎

🤔 既存テーブルがある状態で初期マイグレーションをする

😇 NULLが許可されていないフィールドを追加

😩 マイグレーションを取り消す

😎 データマイグレーション

RunSQL

RunPython

😯 Operation クラス をカスタマイズする

😠 既存データに合わないスキーママイグレーション

😌 同じ親を持つマイグレーション

😱 マイグレーションが10000回を突破する

😅 複数のフィールドをリネームする

😶 ビューをモデルとして登録する

😛 ファクトリで生成した関数をモデルに指定する

😴 複数のデータベースに対してマイグレーションを適用する

🤗 終わりに

😯 Operation クラスをカスタマイズする