mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2025-08-03 18:38:50 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 1

Removed support for syncing apps without migrations per deprecation timeline.

Browse source 
Kept support for creating models without migrations when running tests
(especially for Django's test suite).
This commit is contained in:
Tim Graham 2014-12-26 13:56:08 -05:00
parent 9704b0a82e
commit 7e8cf74dc7
31 changed files with 29 additions and 626 deletions
Download patch file Download diff file Expand all files Collapse all files

25
docs/topics/migrations.txt
View file

@ -136,12 +136,9 @@ database to make sure they work as expected::
$ python manage.py migrate
Operations to perform:
Synchronize unmigrated apps: sessions, admin, messages, auth, staticfiles, contenttypes
Apply all migrations: books
Synchronizing apps without migrations:
Creating tables...
Installing indexes...
Running migrations:
Rendering model states... DONE
Applying books.0003_auto... OK
The command runs in two stages; first, it synchronizes unmigrated apps, and
@ -195,26 +192,6 @@ 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.
.. warning::
Even if things appear to work with unmigrated apps depending on migrated
apps, Django may not generate all the necessary foreign key constraints!
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

10
docs/topics/testing/tools.txt
View file

@ -670,12 +670,12 @@ to test the effects of commit and rollback:
.. warning::
``TestCase`` running on a database that does not support rollback (e.g. MySQL with the
MyISAM storage engine), and all instances of ``TransactionTestCase``, will
roll back at the end of the test by deleting all data from the test database
and reloading initial data for apps without migrations.
``TestCase`` running on a database that does not support rollback (e.g. MySQL
with the MyISAM storage engine), and all instances of ``TransactionTestCase``,
will roll back at the end of the test by deleting all data from the test
database.
Apps with migrations :ref:`will not see their data reloaded <test-case-serialized-rollback>`;
Apps :ref:`will not see their data reloaded <test-case-serialized-rollback>`;
if you need this functionality (for example, third-party apps should enable
this) you can set ``serialized_rollback = True`` inside the
``TestCase`` body.