to be able to write your own, see the :doc:`migration operations reference
</ref/migration-operations>`.
.. _migration-squashing:
...
...
@@ -406,15 +407,19 @@ Squashing is the act of reducing an existing set of many migrations down to
one (or sometimes a few) migrations which still represent the same changes.
Django does this by taking all of your existing migrations, extracting their
Operations and putting them all in sequence, and then running an optimizer
``Operation``\s and putting them all in sequence, and then running an optimizer
over them to try and reduce the length of the list - for example, it knows
that ``CreateModel`` and ``DeleteModel`` cancel each other out, and it knows
that ``AddColumn`` can be rolled into ``CreateModel``.
that :class:`~django.db.migrations.operations.CreateModel` and
:class:`~django.db.migrations.operations.DeleteModel` cancel each other out,
and it knows that :class:`~django.db.migrations.operations.AddField` can be
rolled into :class:`~django.db.migrations.operations.CreateModel`.
Once the operation sequence has been reduced as much as possible - the amount
possible depends on how closely intertwined your models are and if you have
any RunSQL or RunPython operations (which can't be optimized through) - Django
will them write it back out into a new set of initial migration files.
any :class:`~django.db.migrations.operations.RunSQL`
or :class:`~django.db.migrations.operations.RunPython` operations (which can't
be optimized through) - Django will them write it back out into a new set of
initial migration files.
These files are marked to say they replace the previously-squashed migrations,
so they can coexist with the old migration files, and Django will intelligently
...
...
@@ -452,9 +457,9 @@ work::
Note that model interdependencies in Django can get very complex, and squashing
may occasionally result in an optimized migration that doesn't work or is
impossible to run. When this occurs, you can re-try with ``--no-optimize``, but
please file a bug report either way detailing the models and their
relationships so we can improve the optimizer to handle your case.
please `file a bug report <https://code.djangoproject.com/newticket>`_ either
way detailing the models and their relationships so we can improve the
optimizer to handle your case.
.. _migration-serializing:
...
...
@@ -508,7 +513,6 @@ available at the top level of a module it is not serializable.
Django will write out the value as an instantiation of your class with the
given arguments, similar to the way it writes out references to Django fields.
Upgrading from South
--------------------
...
...
@@ -517,9 +521,13 @@ If you already have pre-existing migrations created with
``django.db.migrations`` is quite simple:
* Ensure all installs are fully up-to-date with their migrations
* Delete all your (numbered) migration files, but not the directory or __init__.py - make sure you remove the ``.pyc`` files too.
* Run ``python manage.py makemigrations``. Django should see the empty migration directories and make new initial migrations in the new format.
* Run ``python manage.py migrate``. Django will see that the tables for the initial migrations already exist and mark them as applied without running them.
* Delete all your (numbered) migration files, but not the directory or
``__init__.py`` - make sure you remove the ``.pyc`` files too.
* Run ``python manage.py makemigrations``. Django should see the empty
migration directories and make new initial migrations in the new format.
* Run ``python manage.py migrate``. Django will see that the tables for the
initial migrations already exist and mark them as applied without running
them.
That's it! The only complication is if you have a circular dependency loop
of foreign keys; in this case, ``makemigrations`` might make more than one
