diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/intro/tutorial01.txt | 11 | ||||
| -rw-r--r-- | docs/man/django-admin.1 | 16 | ||||
| -rw-r--r-- | docs/ref/django-admin.txt | 57 | ||||
| -rw-r--r-- | docs/ref/models/fields.txt | 15 | ||||
| -rw-r--r-- | docs/ref/settings.txt | 6 | ||||
| -rw-r--r-- | docs/releases/1.3.txt | 3 | ||||
| -rw-r--r-- | docs/releases/1.7.txt | 5 | ||||
| -rw-r--r-- | docs/spelling_wordlist | 5 | ||||
| -rw-r--r-- | docs/topics/migrations.txt | 25 | ||||
| -rw-r--r-- | docs/topics/testing/tools.txt | 10 |
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. |