Loading docs/ref/models/fields.txt +12 −0 Original line number Diff line number Diff line Loading @@ -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 ~~~~~~~~~~~~~~~~~~~~~~~ Loading Loading @@ -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 ~~~~~~~~~~~~~~~~~~~~~~~ Loading docs/releases/1.7.txt +4 −0 Original line number Diff line number Diff line Loading @@ -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 Loading docs/topics/migrations.txt +15 −0 Original line number Diff line number Diff line Loading @@ -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 Loading Loading
docs/ref/models/fields.txt +12 −0 Original line number Diff line number Diff line Loading @@ -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 ~~~~~~~~~~~~~~~~~~~~~~~ Loading Loading @@ -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 ~~~~~~~~~~~~~~~~~~~~~~~ Loading
docs/releases/1.7.txt +4 −0 Original line number Diff line number Diff line Loading @@ -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 Loading
docs/topics/migrations.txt +15 −0 Original line number Diff line number Diff line Loading @@ -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 Loading
