diff options
| author | Tim Graham <timograham@gmail.com> | 2015-02-09 10:28:42 -0500 |
|---|---|---|
| committer | Tim Graham <timograham@gmail.com> | 2015-02-09 10:28:42 -0500 |
| commit | c5d1a5ef5cf111cd35fa8545a2831dd47ba0fc70 (patch) | |
| tree | 016c4a9de340bcc93dbe4793cf2c15163ebc497f | |
| parent | 2d7c27d3870e57edd1b2ac46b49f0a8804753a1e (diff) | |
Removed docs about unmigrated apps as they are not supported in Django 1.9.
| -rw-r--r-- | docs/ref/django-admin.txt | 3 | ||||
| -rw-r--r-- | docs/spelling_wordlist | 1 | ||||
| -rw-r--r-- | docs/topics/migrations.txt | 8 |
3 files changed, 1 insertions, 11 deletions
diff --git a/docs/ref/django-admin.txt b/docs/ref/django-admin.txt index ed7bd79626..ce3a78f915 100644 --- a/docs/ref/django-admin.txt +++ b/docs/ref/django-admin.txt @@ -696,8 +696,7 @@ Migrations, their relationship with apps and more are covered in depth in The behavior of this command changes depending on the arguments provided: -* No arguments: All migrated apps have all of their migrations run, - and all unmigrated apps are synchronized with the database, +* No arguments: All apps have all of their migrations run. * ``<app_label>``: The specified app has its migrations run, up to the most recent migration. This may involve running other apps' migrations too, due to dependencies. diff --git a/docs/spelling_wordlist b/docs/spelling_wordlist index def6950b04..19c72fc543 100644 --- a/docs/spelling_wordlist +++ b/docs/spelling_wordlist @@ -690,7 +690,6 @@ uniterated unittest unittests unlocalize -unmigrated unparseable unpickle unpickled diff --git a/docs/topics/migrations.txt b/docs/topics/migrations.txt index a0dc365e6d..eaeb6da7c5 100644 --- a/docs/topics/migrations.txt +++ b/docs/topics/migrations.txt @@ -24,11 +24,6 @@ and Django's handling of database schema: * :djadmin:`sqlmigrate`, which displays the SQL statements for a migration. -It's worth noting that migrations are created and run on a per-app basis. -In particular, it's possible to have apps that *do not use migrations* (these -are referred to as "unmigrated" apps) - these apps will instead mimic the -legacy behavior of just adding new models. - You should think of migrations as a version control system for your database schema. ``makemigrations`` is responsible for packaging up your model changes into individual migration files - analogous to commits - and ``migrate`` is @@ -139,9 +134,6 @@ database to make sure they work as expected:: Rendering model states... DONE Applying books.0003_auto... OK -The command runs in two stages; first, it synchronizes unmigrated apps, and -then it runs any migrations that have not yet been applied. - Once the migration is applied, commit the migration and the models change to your version control system as a single commit - that way, when other developers (or your production servers) check out the code, they'll |