Removed support for syncing apps without migrations per deprecation timeline.

Kept support for creating models without migrations when running tests
(especially for Django's test suite).

10 files changed, 18 insertions, 135 deletions

diff --git a/docs/intro/tutorial01.txt b/docs/intro/tutorial01.txt
index e94e0ed16c..5d4eaca76c 100644
--- a/docs/intro/tutorial01.txt
+++ b/docs/intro/tutorial01.txt
@@ -537,16 +537,13 @@ Now, run :djadmin:`migrate` again to create those model tables in your database:
 .. code-block:: bash
 
     $ python manage.py migrate
-
     Operations to perform:
-      Synchronize unmigrated apps: sessions, admin, messages, auth, staticfiles, contenttypes
-      Apply all migrations: polls
-    Synchronizing apps without migrations:
-      Creating tables...
-      Installing indexes...
+      Apply all migrations: admin, contenttypes, polls, auth, sessions
     Running migrations:
+      Rendering model states... DONE
+      ...
       Applying polls.0001_initial... OK
-
+      ...
 
 The :djadmin:`migrate` command takes all the migrations that haven't been
 applied (Django tracks which ones are applied using a special table in your
diff --git a/docs/man/django-admin.1 b/docs/man/django-admin.1
index 32321b4f3c..838953d2e2 100644
--- a/docs/man/django-admin.1
+++ b/docs/man/django-admin.1
@@ -74,22 +74,9 @@ The
 option forces the use of the standard Python interpreter even when IPython is
 installed.
 .TP
-.BI "sql [" "app_label ..." "]"
-Prints the CREATE TABLE SQL statements for the given app name(s).
-.TP
-.BI "sqlall [" "app_label ..." "]"
-Prints the CREATE TABLE, initial\-data and CREATE INDEX SQL statements for the
-given model module name(s).
-.TP
-.BI "sqlclear [" "app_label ..." "]"
-Prints the DROP TABLE SQL statements for the given app name(s).
-.TP
 .BI "sqlflush [" "app_label ..." "]"
 Prints the SQL statements that would be executed for the "flush" command.
 .TP
-.BI "sqlindexes [" "app_label ..." "]"
-Prints the CREATE INDEX SQL statements for the given model module name(s).
-.TP
 .BI "sqlsequencereset [" "app_label ..." "]"
 Prints the SQL statements for resetting PostgreSQL sequences for the
 given app name(s).
@@ -103,8 +90,7 @@ Creates a Django project directory structure for the given project name
 in the current directory or the optional destination.
 .TP
 .BI migrate
-Runs migrations for apps containing migrations, and just creates missing tables
-for apps without migrations.
+Runs migrations for all apps.
 .TP
 .BI "test [" "\-\-verbosity" "] [" "\-\-failfast" "] [" "app_label ..." "]"
 Runs the test suite for the specified applications, or the entire project if
diff --git a/docs/ref/django-admin.txt b/docs/ref/django-admin.txt
index d29213c185..6a26c573aa 100644
--- a/docs/ref/django-admin.txt
+++ b/docs/ref/django-admin.txt
@@ -963,53 +963,6 @@ beyond those apps. Same as ``--list``, applied migrations are marked by an
 ``[X]``. For a verbosity of 2 and above, all dependencies of a migration will
 also be shown.
 
-sql <app_label app_label ...>
------------------------------
-
-.. django-admin:: sql
-
-Prints the CREATE TABLE SQL statements for the given app name(s).
-
-The :djadminopt:`--database` option can be used to specify the database for
-which to print the SQL.
-
-sqlall <app_label app_label ...>
---------------------------------
-
-.. django-admin:: sqlall
-
-Prints the CREATE TABLE and initial-data SQL statements for the given app name(s).
-
-The :djadminopt:`--database` option can be used to specify the database for
-which to print the SQL.
-
-.. versionchanged:: 1.7
-
-    The ``sql*`` management commands now respect the ``allow_migrate()`` method
-    of :setting:`DATABASE_ROUTERS`. If you have models synced to non-default
-    databases, use the :djadminopt:`--database` flag to get SQL for those
-    models (previously they would always be included in the output).
-
-sqlclear <app_label app_label ...>
-----------------------------------
-
-.. django-admin:: sqlclear
-
-Prints the DROP TABLE SQL statements for the given app name(s).
-
-The :djadminopt:`--database` option can be used to specify the database for
-which to print the SQL.
-
-sqldropindexes <app_label app_label ...>
-----------------------------------------
-
-.. django-admin:: sqldropindexes
-
-Prints the DROP INDEX SQL statements for the given app name(s).
-
-The :djadminopt:`--database` option can be used to specify the database for
-which to print the SQL.
-
 sqlflush
 --------
 
@@ -1021,16 +974,6 @@ command.
 The :djadminopt:`--database` option can be used to specify the database for
 which to print the SQL.
 
-sqlindexes <app_label app_label ...>
-------------------------------------
-
-.. django-admin:: sqlindexes
-
-Prints the CREATE INDEX SQL statements for the given app name(s).
-
-The :djadminopt:`--database` option can be used to specify the database for
-which to print the SQL.
-
 sqlmigrate <app_label> <migrationname>
 --------------------------------------
 
diff --git a/docs/ref/models/fields.txt b/docs/ref/models/fields.txt
index 39d728bbce..3fd9d0aace 100644
--- a/docs/ref/models/fields.txt
+++ b/docs/ref/models/fields.txt
@@ -183,8 +183,7 @@ scenes.
 
 .. attribute:: Field.db_index
 
-If ``True``, :djadmin:`django-admin sqlindexes <sqlindexes>` will output a
-``CREATE INDEX`` statement for this field.
+If ``True``, a database index will be created for this field.
 
 ``db_tablespace``
 -----------------
@@ -1120,12 +1119,6 @@ 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
 ~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -1335,12 +1328,6 @@ 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/ref/settings.txt b/docs/ref/settings.txt
index dfbb10c60d..5906cd3c9f 100644
--- a/docs/ref/settings.txt
+++ b/docs/ref/settings.txt
@@ -2397,9 +2397,9 @@ Default: ``[]``
 
 In order to restore the database state between tests for
 ``TransactionTestCase``\s and database backends without transactions, Django
-will :ref:`serialize the contents of all apps with migrations
-<test-case-serialized-rollback>` when it starts the test run so it can then
-reload from that copy before tests that need it.
+will :ref:`serialize the contents of all apps <test-case-serialized-rollback>`
+when it starts the test run so it can then reload from that copy before tests
+that need it.
 
 This slows down the startup time of the test runner; if you have apps that
 you know don't need this feature, you can add their full names in here (e.g.
diff --git a/docs/releases/1.3.txt b/docs/releases/1.3.txt
index 96c0315a76..47dcd5e69b 100644
--- a/docs/releases/1.3.txt
+++ b/docs/releases/1.3.txt
@@ -432,8 +432,7 @@ If you have an existing project that is using the database session
 backend, you don't have to do anything to accommodate this change.
 However, you may get a significant performance boost if you manually
 add the new index to the session table. The SQL that will add the
-index can be found by running the :djadmin:`sqlindexes` admin
-command::
+index can be found by running the ``sqlindexes`` admin command::
 
     python manage.py sqlindexes sessions
 
diff --git a/docs/releases/1.7.txt b/docs/releases/1.7.txt
index e2dc732ae2..f7fc4163b0 100644
--- a/docs/releases/1.7.txt
+++ b/docs/releases/1.7.txt
@@ -74,9 +74,8 @@ but a few of the key features are:
   <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.
-
+  :ref:`ForeignKey <ref-foreignkey>` or :ref:`ManyToManyField <ref-manytomany>`
+  to) apps with migrations.
 
 * If you are upgrading from South, see our :ref:`upgrading-from-south`
   documentation, and third-party app authors should read the
diff --git a/docs/spelling_wordlist b/docs/spelling_wordlist
index 498f03efbd..65f76fa0ca 100644
--- a/docs/spelling_wordlist
+++ b/docs/spelling_wordlist
@@ -582,12 +582,7 @@ spam
 spammers
 spatialite
 Springmeyer
-sql
-sqlall
-sqlclear
-sqldropindexes
 sqlflush
-sqlindexes
 sqlmigrate
 sqlsequencereset
 squashmigrations
diff --git a/docs/topics/migrations.txt b/docs/topics/migrations.txt
index 9c56574857..31d26cb8d7 100644
--- a/docs/topics/migrations.txt
+++ b/docs/topics/migrations.txt
@@ -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
diff --git a/docs/topics/testing/tools.txt b/docs/topics/testing/tools.txt
index 3fabf63c44..9d3ae456fd 100644
--- a/docs/topics/testing/tools.txt
+++ b/docs/topics/testing/tools.txt
@@ -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.