mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2025-09-26 12:09:19 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 4

Implement allow_migrate for migration operations

Browse source
This commit is contained in:
Andrew Godwin 2013-07-30 12:34:31 +01:00
parent 12e9804d16
commit fddc5957c5
6 changed files with 156 additions and 44 deletions
Download patch file Download diff file Expand all files Collapse all files

10
docs/topics/db/multi-db.txt
View file

@ -163,8 +163,14 @@ A database Router is a class that provides up to four methods:
the router has no opinion. This method can be used to determine
the availability of a model on a given database.
Note that if this returns ``True`` for an app with migrations but
``False`` for an app those migrations depend on, Django will error.
Note that migrations will just silently not perform any operations
on a model for which this returns ``False``. This may result in broken
ForeignKeys, extra tables or missing tables if you change it once you
have applied some migrations.
The value passed for ``model`` may be a
:ref:`historical model <historical-models>`, and thus not have any
custom attributes, methods or managers. You should only rely on ``_meta``.
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

23
docs/topics/migrations.txt
View file

@ -272,3 +272,26 @@ Note that this only works given two things:
* You have not manually edited your database - Django won't be able to detect
that your database doesn't match your models, you'll just get errors when
migrations try and modify those tables.
.. historical-models:
Historical models
-----------------
When you run migrations, Django is working from historical versions of
your models stored in the migration files. If you write Python code
using the ``django.db.migrations.RunPython`` operation, or if you have
``allow_migrate`` methods on your database routers, you will be exposed
to these versions of your models.
Because it's impossible to serialize arbitrary Python code, these historical
models will not have any custom methods or managers that you have defined.
They will, however, have the same fields, relationships and ``Meta`` options
(also versioned, so they may be different from your current ones).
In addition, the base classes of the model are just stored as pointers,
so you must always keep base classes around for as long as there is a migration
that contains a reference to them. On the plus side, methods and managers
from these base classes inherit normally, so if you absolutely need access
to these you can opt to move them into a superclass.