summaryrefslogtreecommitdiff
path: root/docs/howto/writing-migrations.txt
blob: 59a636626ae93c666c1311608cda853add5f7035 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
===========================
Writing database migrations
===========================

This document explains how to structure and write database migrations for
different scenarios you might encounter. For introductory material on
migrations, see :doc:`the topic guide </topics/migrations>`.

.. _data-migrations-and-multiple-databases:

Data migrations and multiple databases
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

When using multiple databases, you may need to figure out whether or not to
run a migration against a particular database. For example, you may want to
**only** run a migration on a particular database.

In order to do that you can check the database connection's alias inside a
``RunPython`` operation by looking at the ``schema_editor.connection.alias``
attribute::

    from django.db import migrations

    def forwards(apps, schema_editor):
        if not schema_editor.connection.alias == 'default':
            return
        # Your migration code goes here

    class Migration(migrations.Migration):

        dependencies = [
            # Dependencies to other migrations
        ]

        operations = [
            migrations.RunPython(forwards),
        ]

.. versionadded:: 1.8

You can also provide hints that will be passed to the :meth:`allow_migrate()`
method of database routers as ``**hints``:

.. snippet::
    :filename: myapp/dbrouters.py

    class MyRouter(object):

        def allow_migrate(self, db, model, **hints):
            if 'target_db' in hints:
                return db == hints['target_db']
            return True

Then, to leverage this in your migrations, do the following::

    from django.db import migrations

    def forwards(apps, schema_editor):
        # Your migration code goes here

    class Migration(migrations.Migration):

        dependencies = [
            # Dependencies to other migrations
        ]

        operations = [
            migrations.RunPython(forwards, hints={'target_db': 'default'}),
        ]

Migrations that add unique fields
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Applying a "plain" migration that adds a unique non-nullable field to a table
with existing rows will raise an error because the value used to populate
existing rows is generated only once, thus breaking the unique constraint.

Therefore, the following steps should be taken. In this example, we'll add a
non-nullable :class:`~django.db.models.UUIDField` with a default value. Modify
the respective field according to your needs.

* Add the field on your model with ``default=...`` and ``unique=True``
  arguments. In the example, we use ``uuid.uuid4`` for the default.

* Run the :djadmin:`makemigrations` command.

* Edit the created migration file.

  The generated migration class should look similar to this::

    class Migration(migrations.Migration):

        dependencies = [
            ('myapp', '0003_auto_20150129_1705'),
        ]

        operations = [
            migrations.AddField(
                model_name='mymodel',
                name='uuid',
                field=models.UUIDField(max_length=32, unique=True, default=uuid.uuid4),
            ),
        ]

  You will need to make three changes:

  * Add a second :class:`~django.db.migrations.operations.AddField` operation
    copied from the generated one and change it to
    :class:`~django.db.migrations.operations.AlterField`.

  * On the first operation (``AddField``), change ``unique=True`` to
    ``null=True`` -- this will create the intermediary null field.

  * Between the two operations, add a
    :class:`~django.db.migrations.operations.RunPython` or
    :class:`~django.db.migrations.operations.RunSQL` operation to generate a
    unique value (UUID in the example) for each existing row.

  The resulting migration should look similar to this::

    # -*- coding: utf-8 -*-
    from __future__ import unicode_literals

    from django.db import migrations, models
    import uuid

    def gen_uuid(apps, schema_editor):
        MyModel = apps.get_model('myapp', 'MyModel')
        for row in MyModel.objects.all():
            row.uuid = uuid.uuid4()
            row.save()

    class Migration(migrations.Migration):

        dependencies = [
            ('myapp', '0003_auto_20150129_1705'),
        ]

        operations = [
            migrations.AddField(
                model_name='mymodel',
                name='uuid',
                field=models.UUIDField(default=uuid.uuid4, null=True),
            ),
            # omit reverse_code=... if you don't want the migration to be reversible.
            migrations.RunPython(gen_uuid, reverse_code=migrations.RunPython.noop),
            migrations.AlterField(
                model_name='mymodel',
                name='uuid',
                field=models.UUIDField(default=uuid.uuid4, unique=True),
            ),
        ]

* Now you can apply the migration as usual with the :djadmin:`migrate` command.

  Note there is a race condition if you allow objects to be created while this
  migration is running. Objects created after the ``AddField`` and before
  ``RunPython`` will have their original ``uuid``’s overwritten.