---
title: "マイグレーション操作"
version: 3.0
locale: ja
source: https://docs.djangoproject.com/ja/3.0/ref/migration-operations/
canonical: https://djangodocs.dev/ja/3.0/ref/migration-operations/
---
# マイグレーション操作

マイグレーションファイルは一つ以上の `オペレーション`、データベースに対してマイグレーションが行うべき操作を宣言的に保持するオブジェクト、から構成されます。

加えて Django はモデルが過去からどのように変遷したかを解明するため、またマイグレーションを自動的に記述できるように最後のマイグレーション以降モデルに対して行われた変更を導出するために、これらの `オペレーション` オブジェクトを利用します;マイグレーションの定義が宣言的であるのはそのためで、これは Django がプロジェクトの全容がどういった物であるかを解析する際、データベースを直接操作することなく、容易にマイグレーション定義を全てメモリ上にロードして処理できる事を意味します。

[データのマイグレーション](/ja/3.0/topics/migrations/#data-migrations) や高度なデータベースへの手動操作のような特別な `オペレーション` も存在します。もし頻繁に行われる独自の変更をカプセル化したければ独自に `オペレーション` を記述する事もできます。

If you need an empty migration file to write your own `Operation` objects
into, use `python manage.py makemigrations --empty yourappname`, but be aware
that manually adding schema-altering operations can confuse the migration
autodetector and make resulting runs of [`makemigrations`](/ja/3.0/ref/django-admin/#django-admin-makemigrations) output
incorrect code.

Django が提供するコア機能は全て `django.db.migrations.operations` モジュールから利用できます。

より入門的な内容に関しては、 [トピックスのマイグレーション](/ja/3.0/topics/migrations/) を参照ください。

## スキーマ操作

### `CreateModel`

#### `class CreateModel(name, fields, options=None, bases=None, managers=None)`

プロジェクトの履歴に新たなモデル、そしてデータベース上に対応するテーブルを作成します。

`name` は `models.py` ファイルに定義されているであろうモデルの名称です。

`fields` は `(フィールド名, フィールドのインスタンス)` という 2 値のタプルのリストです。フィールドのインスタンスは束縛されないフィールド(他のモデルから取得した物でなく、単に `models.CharField(...)` 等と記述する物)でなければいけません。

`options` は定義されるモデルの `Meta` クラスの値からなるオプションの辞書オブジェクトです。

`bases` is an optional list of other classes to have this model inherit from;
it can contain both class objects as well as strings in the format
`"appname.ModelName"` if you want to depend on another model (so you inherit
from the historical version). If it's not supplied, it defaults to inheriting
from the standard `models.Model`.

`managers` は `(マネージャ名, マネージャのインスタンス)` という 2 値のタプルのリストを受け取ります。マイグレーションの間はリスト内で最初に定義されたマネージャがこのモデルの標準マネージャとして利用されます。

### `DeleteModel`

#### `class DeleteModel(name)`

プロジェクトの履歴からモデルを、加えてデータベースから該当モデルを扱うテーブルを削除します。

### `RenameModel`

#### `class RenameModel(old_name, new_name)`

モデルの名称を今までの名称から新しい名称に変更します。

一度に定義しているモデルの名前とかなり多くのフィールドの名前を変更した場合は手動でこの処理を追加する必要があるかもしれません;マイグレーションの自動検知機構が古い名称を持ったモデルを削除して異なった名称のモデルを追加したと認識してしまうため、そのマイグレーション処理は古いテーブルの全てのデータを消去してしまいます。

### `AlterModelTable`

#### `class AlterModelTable(name, table)`

定義しているモデルのテーブル名を変更します(`Meta` サブクラスの [`db_table`](/ja/3.0/ref/models/options/#django.db.models.Options.db_table) オプションを参照します)。

### `AlterUniqueTogether`

#### `class AlterUniqueTogether(name, unique_together)`

Changes the model's set of unique constraints (the
[`unique_together`](/ja/3.0/ref/models/options/#django.db.models.Options.unique_together) option on the `Meta`
subclass).

### `AlterIndexTogether`

#### `class AlterIndexTogether(name, index_together)`

Changes the model's set of custom indexes (the
[`index_together`](/ja/3.0/ref/models/options/#django.db.models.Options.index_together) option on the `Meta`
subclass).

### `AlterOrderWithRespectTo`

#### `class AlterOrderWithRespectTo(name, order_with_respect_to)`

Makes or deletes the `_order` column needed for the
[`order_with_respect_to`](/ja/3.0/ref/models/options/#django.db.models.Options.order_with_respect_to) option on the `Meta`
subclass.

### `AlterModelOptions`

#### `class AlterModelOptions(name, options)`

Stores changes to miscellaneous model options (settings on a model's `Meta`)
like `permissions` and `verbose_name`. Does not affect the database, but
persists these changes for [`RunPython`](#django.db.migrations.operations.RunPython) instances to use. `options`
should be a dictionary mapping option names to values.

### `AlterModelManagers`

#### `class AlterModelManagers(name, managers)`

Alters the managers that are available during migrations.

### `AddField`

#### `class AddField(model_name, name, field, preserve_default=True)`

Adds a field to a model. `model_name` is the model's name, `name` is
the field's name, and `field` is an unbound Field instance (the thing
you would put in the field declaration in `models.py` \- for example,
`models.IntegerField(null=True)`.

The `preserve_default` argument indicates whether the field's default
value is permanent and should be baked into the project state (`True`),
or if it is temporary and just for this migration (`False`) - usually
because the migration is adding a non-nullable field to a table and needs
a default value to put into existing rows. It does not affect the behavior
of setting defaults in the database directly - Django never sets database
defaults and always applies them in the Django ORM code.

> **Warning**
>
> On older databases, adding a field with a default value may cause a full
> rewrite of the table. This happens even for nullable fields and may have a
> negative performance impact. To avoid that, the following steps should be
> taken.
>
> - Add the nullable field without the default value and run the
>   [`makemigrations`](/ja/3.0/ref/django-admin/#django-admin-makemigrations) command. This should generate a migration with
>   an `AddField` operation.
> - Add the default value to your field and run the [`makemigrations`](/ja/3.0/ref/django-admin/#django-admin-makemigrations)
>   command. This should generate a migration with an `AlterField`
>   operation.

### `RemoveField`

#### `class RemoveField(model_name, name)`

Removes a field from a model.

Bear in mind that when reversed, this is actually adding a field to a model.
The operation is reversible (apart from any data loss, which of course is
irreversible) if the field is nullable or if it has a default value that can be
used to populate the recreated column. If the field is not nullable and does
not have a default value, the operation is irreversible.

### `AlterField`

#### `class AlterField(model_name, name, field, preserve_default=True)`

Alters a field's definition, including changes to its type,
[`null`](/ja/3.0/ref/models/fields/#django.db.models.Field.null), [`unique`](/ja/3.0/ref/models/fields/#django.db.models.Field.unique),
[`db_column`](/ja/3.0/ref/models/fields/#django.db.models.Field.db_column) and other field attributes.

The `preserve_default` argument indicates whether the field's default
value is permanent and should be baked into the project state (`True`),
or if it is temporary and just for this migration (`False`) - usually
because the migration is altering a nullable field to a non-nullable one and
needs a default value to put into existing rows. It does not affect the
behavior of setting defaults in the database directly - Django never sets
database defaults and always applies them in the Django ORM code.

Note that not all changes are possible on all databases - for example, you
cannot change a text-type field like `models.TextField()` into a number-type
field like `models.IntegerField()` on most databases.

### `RenameField`

#### `class RenameField(model_name, old_name, new_name)`

Changes a field's name (and, unless [`db_column`](/ja/3.0/ref/models/fields/#django.db.models.Field.db_column)
is set, its column name).

### `AddIndex`

#### `class AddIndex(model_name, index)`

Creates an index in the database table for the model with `model_name`.
`index` is an instance of the [`Index`](/ja/3.0/ref/models/indexes/#django.db.models.Index) class.

### `RemoveIndex`

#### `class RemoveIndex(model_name, name)`

Removes the index named `name` from the model with `model_name`.

### `AddConstraint`

#### `class AddConstraint(model_name, constraint)`

> **New in Django 2.2**

Creates a [constraint](/ja/3.0/ref/models/constraints/) in the database table for
the model with `model_name`.

### `RemoveConstraint`

#### `class RemoveConstraint(model_name, name)`

> **New in Django 2.2**

Removes the constraint named `name` from the model with `model_name`.

## 特別な操作

### `RunSQL`

#### `class RunSQL(sql, reverse_sql=None, state_operations=None, hints=None, elidable=False)`

Allows running of arbitrary SQL on the database - useful for more advanced
features of database backends that Django doesn't support directly.

`sql`, and `reverse_sql` if provided, should be strings of SQL to run on
the database. On most database backends (all but PostgreSQL), Django will
split the SQL into individual statements prior to executing them.

> **Warning**
>
> On PostgreSQL and SQLite, only use `BEGIN` or `COMMIT` in your SQL in
> [non-atomic migrations](/ja/3.0/howto/writing-migrations/#non-atomic-migrations), to avoid breaking
> Django's transaction state.

文字列もしくは 2 値のタプルのリストを渡すことができます。その内後者はクエリとパラメータを [cursor.execute()](/ja/3.0/topics/db/sql/#executing-custom-sql) において行うのと同じ形式で渡すために用いられます。以下の 3 つの処理は互いに等価です:

```
migrations.RunSQL("INSERT INTO musician (name) VALUES ('Reinhardt');")
migrations.RunSQL([("INSERT INTO musician (name) VALUES ('Reinhardt');", None)])
migrations.RunSQL([("INSERT INTO musician (name) VALUES (%s);", ['Reinhardt'])])
```

クエリにパーセント文字リテラルを含ませたい場合、パラメータを渡していればパーセント文字を二重に記述する必要が有ります。

The `reverse_sql` queries are executed when the migration is unapplied. They
should undo what is done by the `sql` queries. For example, to undo the above
insertion with a deletion:

```
migrations.RunSQL(
    sql=[("INSERT INTO musician (name) VALUES (%s);", ['Reinhardt'])],
    reverse_sql=[("DELETE FROM musician where name=%s;", ['Reinhardt'])],
)
```

If `reverse_sql` is `None` (the default), the `RunSQL` operation is
irreversible.

The `state_operations` argument allows you to supply operations that are
equivalent to the SQL in terms of project state. For example, if you are
manually creating a column, you should pass in a list containing an `AddField`
operation here so that the autodetector still has an up-to-date state of the
model. If you don't, when you next run `makemigrations`, it won't see any
operation that adds that field and so will try to run it again. For example:

```
migrations.RunSQL(
    "ALTER TABLE musician ADD COLUMN name varchar(255) NOT NULL;",
    state_operations=[
        migrations.AddField(
            'musician',
            'name',
            models.CharField(max_length=255),
        ),
    ],
)
```

オプションの `hints` 引数はデータベースルータオブジェクトの [`allow_migrate()`](/ja/3.0/topics/db/multi-db/#allow_migrate) メソッドに `**hints` として渡されてルーティングの決定を補助します。データベースのヒントに関しての詳細は [Hints](/ja/3.0/topics/db/multi-db/#topics-db-multi-db-hints) を参照ください。

オプションの `elidable` 引数はこの処理を [マイグレーションの統合](/ja/3.0/topics/migrations/#migration-squashing) を行った際に消去する(省略する)か否かを決定します。

#### `RunSQL.noop`

指定された順序での処理を行わない場合、`sql` もしくは `reverse_sql` に対して `RunSQL.noop` 要素を渡します。これは特に処理を逆の順序で行いたい場合に有用です。

### `RunPython`

#### `class RunPython(code, reverse_code=None, atomic=None, hints=None, elidable=False)`

マイグレーション履歴を反映して独自の Python コードを実行します。`code` (与えられれば加えて `reverse_code` )は二つの引数を受け取る呼び出し可能オブジェクトでなければなりません;第一引数はプロジェクトの履歴において処理の場所が一致している履歴を反映したモデルを含んだ `django.apps.registry.Apps` のインスタンスであり、第二引数は [`SchemaEditor`](/ja/3.0/ref/schema-editor/#django.db.backends.base.schema.BaseDatabaseSchemaEditor) のインスタンスです。

The `reverse_code` argument is called when unapplying migrations. This
callable should undo what is done in the `code` callable so that the
migration is reversible. If `reverse_code` is `None` (the default), the
`RunPython` operation is irreversible.

オプションの `hints` 引数はルーティングの決定を補助するためにデータベースルータの [`allow_migrate()`](/ja/3.0/topics/db/multi-db/#allow_migrate) メソッドに `**hints` として渡されます。データベースのヒントに関しての詳細は [Hints](/ja/3.0/topics/db/multi-db/#topics-db-multi-db-hints) を参照してください。

オプションの `elidable` 引数はこの処理を [マイグレーションの統合](/ja/3.0/topics/migrations/#migration-squashing) を行った際に消去する(省略する)か否かを決定します。

You are advised to write the code as a separate function above the `Migration`
class in the migration file, and pass it to `RunPython`. Here's an example of
using `RunPython` to create some initial objects on a `Country` model:

```
from django.db import migrations

def forwards_func(apps, schema_editor):
    # We get the model from the versioned app registry;
    # if we directly import it, it'll be the wrong version
    Country = apps.get_model("myapp", "Country")
    db_alias = schema_editor.connection.alias
    Country.objects.using(db_alias).bulk_create([
        Country(name="USA", code="us"),
        Country(name="France", code="fr"),
    ])

def reverse_func(apps, schema_editor):
    # forwards_func() creates two Country instances,
    # so reverse_func() should delete them.
    Country = apps.get_model("myapp", "Country")
    db_alias = schema_editor.connection.alias
    Country.objects.using(db_alias).filter(name="USA", code="us").delete()
    Country.objects.using(db_alias).filter(name="France", code="fr").delete()

class Migration(migrations.Migration):

    dependencies = []

    operations = [
        migrations.RunPython(forwards_func, reverse_func),
    ]
```

これは [データのマイグレーション](/ja/3.0/topics/migrations/#data-migrations) の作成、独自のデータ更新と構成変更、そして ORM や Python のコードにアクセスを必要とするあらゆる操作のために行われる一般的な操作です。

[`RunSQL`](#django.db.migrations.operations.RunSQL) と同様、もし内部のスキーマを変更する場合は Django のモデル機構のスコープ範囲外(例えば triggers 等)で行うか、もしくはモデルの状態に変更を反映する処理に [`SeparateDatabaseAndState`](#django.db.migrations.operations.SeparateDatabaseAndState) を追加する事を心がけてください - そうでなければ、バージョン管理された ORM およびマイグレーションの自動検出機構が正常に動作しなくなります。

標準では `RunPython` は DDL トランザクションをサポートしないデータベース(例えば MySQL と Oracle 等)上では通常のトランザクション内で記述された内容の処理を行います。この仕組みは安全ではありますが、これらのデータベースバックエンドを利用中に `schema_editor` を利用しようとするとクラッシュを引き起こす場合が有ります;このような場合は、`RunPython` に対して `atomic=False` を渡してください。

トランザクション中の DDL 使用をサポートしているデータベース(SQLite や PostgreSQL)においては、`RunPython` は各マイグレーションに対して作成されたトランザクション以外に自動的にトランザクションを保持しません。そのため、例えば PostgreSQL では、スキーマ変更と `RunPython` を同一のマイグレーション内で結合させて用いるのは避けるべきであり、そうしなければ `OperationalError: cannot ALTER TABLE "mytable" because it has pending trigger events` のようなエラーに遭遇する可能性が有ります。

もしここまでに挙げられた物と異なるデータベースを利用しておりトランザクション中の DDL 事項をサポートしているか不明な場合、 `django.db.connection.features.can_rollback_ddl` 属性を確認してください。

もし `RunPython` 操作が [非アトミックなマイグレーション](/ja/3.0/howto/writing-migrations/#non-atomic-migrations) の一部である場合、その操作は `RunPython` 操作に対して `atomic=True` が渡されて生成されたトランザクション中においてのみ実行されます。

> **Warning**
>
> `RunPython` はモデルのデータベース接続を魔法のように切り替える事はしません;データベースのエイリアス(作成した関数の第二引数 `schema_editor` 内、 `schema_editor.connection.alias` から利用可能)を指定していないモデルのメソッドはすべてデフォルトのデータベースを利用します。

#### `static RunPython.noop()`

指定された順序で処理を行いたくない場合は `code` もしくは `reverse_code` に `RunPython.noop` メソッドを渡してください。この指定は処理を逆順で行いたい場合に特に有用です。

### `SeparateDatabaseAndState`

#### `class SeparateDatabaseAndState(database_operations=None, state_operations=None)`

A highly specialized operation that lets you mix and match the database
(schema-changing) and state (autodetector-powering) aspects of operations.

It accepts two lists of operations. When asked to apply state, it will use the
`state_operations` list (this is a generalized version of [`RunSQL`](#django.db.migrations.operations.RunSQL)'s
`state_operations` argument). When asked to apply changes to the database, it
will use the `database_operations` list.

If the actual state of the database and Django's view of the state get out of
sync, this can break the migration framework, even leading to data loss. It's
worth exercising caution and checking your database and state operations
carefully. You can use [`sqlmigrate`](/ja/3.0/ref/django-admin/#django-admin-sqlmigrate) and [`dbshell`](/ja/3.0/ref/django-admin/#django-admin-dbshell) to check
your database operations. You can use [`makemigrations`](/ja/3.0/ref/django-admin/#django-admin-makemigrations), especially
with [`--dry-run`](/ja/3.0/ref/django-admin/#cmdoption-makemigrations-dry-run), to check your state
operations.

For an example using `SeparateDatabaseAndState`, see
[Changing a ManyToManyField to use a through model](/ja/3.0/howto/writing-migrations/#changing-a-manytomanyfield-to-use-a-through-model).

## 自分で操作を書く

オペレーションは比較的シンプルな API を持っており、Django に内蔵された機能を独自に補助する処理を簡単に記述できるよう設計されています。`Operation` の基本構造は以下のようなものです:

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

class MyCustomOperation(Operation):

    # If this is False, it means that this operation will be ignored by
    # sqlmigrate; if true, it will be run and the SQL collected for its output.
    reduces_to_sql = False

    # If this is False, Django will refuse to reverse past this operation.
    reversible = False

    def __init__(self, arg1, arg2):
        # Operations are usually instantiated with arguments in migration
        # files. Store the values of them on self for later use.
        pass

    def state_forwards(self, app_label, state):
        # The Operation should take the 'state' parameter (an instance of
        # django.db.migrations.state.ProjectState) and mutate it to match
        # any schema changes that have occurred.
        pass

    def database_forwards(self, app_label, schema_editor, from_state, to_state):
        # The Operation should use schema_editor to apply any changes it
        # wants to make to the database.
        pass

    def database_backwards(self, app_label, schema_editor, from_state, to_state):
        # If reversible is True, this is called when the operation is reversed.
        pass

    def describe(self):
        # This is used to describe what the operation does in console output.
        return "Custom Operation"
```

You can take this template and work from it, though we suggest looking at the
built-in Django operations in `django.db.migrations.operations` \- they cover
a lot of the example usage of semi-internal aspects of the migration framework
like `ProjectState` and the patterns used to get historical models, as well
as `ModelState` and the patterns used to mutate historical models in
`state_forwards()`.

いくつかの注意すべき点

- You don't need to learn too much about `ProjectState` to write migrations;
  just know that it has an `apps` property that gives access to an app
  registry (which you can then call `get_model` on).
- `database_forwards` and `database_backwards` both get two states passed
  to them; these represent the difference the `state_forwards` method would
  have applied, but are given to you for convenience and speed reasons.
- If you want to work with model classes or model instances from the
  `from_state` argument in `database_forwards()` or
  `database_backwards()`, you must render model states using the
  `clear_delayed_apps_cache()` method to make related models available:

  ```
  def database_forwards(self, app_label, schema_editor, from_state, to_state):
      # This operation should have access to all models. Ensure that all models are
      # reloaded in case any are delayed.
      from_state.clear_delayed_apps_cache()
      ...
  ```
- database\_backwards メソッドにおける `to_state` は *古い* 状態を示します;そのため、その値はマイグレーションが状態を戻した場合は現在の状態となります。
- 内蔵されたオペレーションにおいて `references_model` が実装されているのを見つけるかもしれません;これは独自のオペレーションのためでなく自動検知機構のコードの一部として存在しています。

> **Warning**
>
> パフォーマンス上の理由から、`ModelState.fields` 内の [`Field`](/ja/3.0/ref/models/fields/#django.db.models.Field) のインスタンスはマイグレーション間で再利用されます。これらのインスタンスの属性を決して変更してはいけません。`state_forwards()` 内のフィールドを変更したい場合は、`ModelState.fields` から古いインスタンスを削除して新たなインスタンスと置き換える必要が有ります。`ModelState.managers` 内の [`Manager`](/ja/3.0/topics/db/managers/#django.db.models.Manager) のインスタンスについても同様です。

As an example, let's make an operation that loads PostgreSQL extensions (which
contain some of PostgreSQL's more exciting features). Since there's no model
state changes, all it does is run one command:

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

class LoadExtension(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("CREATE EXTENSION IF NOT EXISTS %s" % self.name)

    def database_backwards(self, app_label, schema_editor, from_state, to_state):
        schema_editor.execute("DROP EXTENSION %s" % self.name)

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