Refs #25850, #27142, #27110 -- Documented migration history consistency checks.

This commit is contained in:
Shai Berger 2016-09-01 23:19:47 +03:00 committed by Tim Graham
parent de7f9758ac
commit c93ac9cf42
3 changed files with 39 additions and 5 deletions

View file

@ -98,10 +98,22 @@ the database name would raise an error. For the second example::
Using other management commands
-------------------------------
The other ``django-admin`` commands that interact with the database operate in
Most other ``django-admin`` commands that interact with the database operate in
the same way as :djadmin:`migrate` -- they only ever operate on one database at
a time, using ``--database`` to control the database used.
An exception to this rule is the :djadmin:`makemigrations` command. It
validates the migration history in the databases to catch problems with the
existing migration files (which could be caused by editing them) before
creating new migrations. By default, it checks only the ``default`` database,
but it consults the the :meth:`allow_migrate` method of :ref:`routers
<topics-db-multi-db-routing>` if any are installed.
.. versionchanged:: 1.10
Migration consistency checks were added. Checks based on database routers
were added in 1.10.1.
.. _topics-db-multi-db-routing:
Automatic database routing
@ -188,7 +200,8 @@ A database Router is a class that provides up to four methods:
``model_name`` will be silently skipped when running :djadmin:`migrate` on
the ``db``. Changing the behavior of ``allow_migrate()`` for models that
already have migrations may result in broken foreign keys, extra tables,
or missing tables.
or missing tables. When :djadmin:`makemigrations` verifies the migration
history, it skips databases where no app is allowed to migrate.
A router doesn't have to provide *all* these methods -- it may omit one
or more of them. If one of the methods is omitted, Django will skip