summaryrefslogtreecommitdiff
path: root/docs
diff options
context:
space:
mode:
authorAndrew Godwin <andrew@aeracode.org>2014-06-15 11:46:56 -0700
committerAndrew Godwin <andrew@aeracode.org>2014-06-15 11:47:23 -0700
commit24afb1d7a746da131212d050404bbe8837cf6f1d (patch)
treec8ac9c3945443364566aa6886da275194583908c /docs
parentedd9f8a7b2beb0fe2f83a9e50157c45364753121 (diff)
Fixed #22660: Doc'd you can't have unmigrated apps depend on migrated
Diffstat (limited to 'docs')
-rw-r--r--docs/ref/models/fields.txt12
-rw-r--r--docs/releases/1.7.txt4
-rw-r--r--docs/topics/migrations.txt15
3 files changed, 31 insertions, 0 deletions
diff --git a/docs/ref/models/fields.txt b/docs/ref/models/fields.txt
index afdc348685..5148c68c5d 100644
--- a/docs/ref/models/fields.txt
+++ b/docs/ref/models/fields.txt
@@ -1062,6 +1062,12 @@ avoid the overhead of an index if you are creating a foreign key for
consistency rather than joins, or if you will be creating an alternative index
like a partial or multiple column index.
+.. warning::
+
+ It is not recommended to have a ``ForeignKey`` from an app without migrations
+ to an app with migrations. See the :ref:`dependencies documentation
+ <unmigrated-dependencies>` for more details.
+
Database Representation
~~~~~~~~~~~~~~~~~~~~~~~
@@ -1261,6 +1267,12 @@ which the model is related, which works exactly the same as it does for
Related objects can be added, removed, or created with the field's
:class:`~django.db.models.fields.related.RelatedManager`.
+.. warning::
+
+ It is not recommended to have a ``ManyToManyField`` from an app without migrations
+ to an app with migrations. See the :ref:`dependencies documentation
+ <unmigrated-dependencies>` for more details.
+
Database Representation
~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/docs/releases/1.7.txt b/docs/releases/1.7.txt
index 560f0562e9..7950487731 100644
--- a/docs/releases/1.7.txt
+++ b/docs/releases/1.7.txt
@@ -68,6 +68,10 @@ but a few of the key features are:
inside ``TransactionTestCase`` :ref:`unless specifically requested
<test-case-serialized-rollback>`.
+* It is not advised to have apps without migrations depend on (have a
+ :ref:`ForeignKey <ref-foreignkey>` or :ref:`ManyToManyField <ref-manytomany>` to) apps with migrations. Read the
+ :ref:`dependencies documentation <unmigrated-dependencies>` for more.
+
.. _app-loading-refactor-17-release-note:
App-loading refactor
diff --git a/docs/topics/migrations.txt b/docs/topics/migrations.txt
index 40ce520a03..a4fc5c9e52 100644
--- a/docs/topics/migrations.txt
+++ b/docs/topics/migrations.txt
@@ -201,6 +201,21 @@ restrict to a single app. Restricting to a single app (either in
a guarantee; any other apps that need to be used to get dependencies correct
will be.
+.. _unmigrated-dependencies:
+
+Be aware, however, that unmigrated apps cannot depend on migrated apps, by the
+very nature of not having migrations. This means that it is not generally
+possible to have an unmigrated app have a ForeignKey or ManyToManyField to
+a migrated app; some cases may work, but it will eventually fail.
+
+This is particularly apparent if you use swappable models (e.g.
+``AUTH_USER_MODEL``), as every app that uses swappable models will need
+to have migrations if you're unlucky. As time goes on, more and more
+third-party apps will get migrations, but in the meantime you can either
+give them migrations yourself (using :setting:`MIGRATION_MODULES` to
+store those modules outside of the app's own module if you wish), or
+keep the app with your user model unmigrated.
+
.. _migration-files:
Migration files