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 /docs/topics | |
| parent | 2d7c27d3870e57edd1b2ac46b49f0a8804753a1e (diff) | |
Removed docs about unmigrated apps as they are not supported in Django 1.9.
Diffstat (limited to 'docs/topics')
| -rw-r--r-- | docs/topics/migrations.txt | 8 |
1 files changed, 0 insertions, 8 deletions
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 |