diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/howto/initial-data.txt | 15 | ||||
| -rw-r--r-- | docs/ref/django-admin.txt | 6 | ||||
| -rw-r--r-- | docs/topics/testing/overview.txt | 5 | ||||
| -rw-r--r-- | docs/topics/testing/tools.txt | 12 |
4 files changed, 0 insertions, 38 deletions
diff --git a/docs/howto/initial-data.txt b/docs/howto/initial-data.txt index b7e00d1346..6b40c5a5d8 100644 --- a/docs/howto/initial-data.txt +++ b/docs/howto/initial-data.txt @@ -76,21 +76,6 @@ from the fixture and re-loaded into the database. Note this means that if you change one of the rows created by a fixture and then run :djadmin:`loaddata` again, you'll wipe out any changes you've made. -Automatically loading initial data fixtures -------------------------------------------- - -.. deprecated:: 1.7 - - If an application uses migrations, there is no automatic loading of - fixtures. Since migrations will be required for applications in Django 1.9, - this behavior is considered deprecated. If you want to load initial data - for an app, consider doing it in a :ref:`data migration <data-migrations>`. - -If you create a fixture named ``initial_data.[xml/yaml/json]``, that fixture will -be loaded every time you run :djadmin:`migrate`. This is extremely convenient, -but be careful: remember that the data will be refreshed *every time* you run -:djadmin:`migrate`. So don't use ``initial_data`` for data you'll want to edit. - Where Django finds fixture files -------------------------------- diff --git a/docs/ref/django-admin.txt b/docs/ref/django-admin.txt index 728432eecc..29c9537dad 100644 --- a/docs/ref/django-admin.txt +++ b/docs/ref/django-admin.txt @@ -341,12 +341,6 @@ prompts. The :djadminopt:`--database` option may be used to specify the database to flush. -``--no-initial-data`` -~~~~~~~~~~~~~~~~~~~~~ - -Use ``--no-initial-data`` to avoid loading the initial_data fixture. - - inspectdb --------- diff --git a/docs/topics/testing/overview.txt b/docs/topics/testing/overview.txt index 0aca7fb0a4..57bdfaa0ca 100644 --- a/docs/topics/testing/overview.txt +++ b/docs/topics/testing/overview.txt @@ -260,9 +260,6 @@ The initial serialization is usually very quick, but if you wish to exclude some apps from this process (and speed up test runs slightly), you may add those apps to :setting:`TEST_NON_SERIALIZED_APPS`. -Apps without migrations are not affected; ``initial_data`` fixtures are -reloaded as usual. - Other test conditions --------------------- @@ -288,8 +285,6 @@ prepares itself. You can control the level of detail of these messages with the Creating test database... Creating table myapp_animal Creating table myapp_mineral - Loading 'initial_data' fixtures... - No fixtures found. This tells you that the test runner is creating a test database, as described in the previous section. diff --git a/docs/topics/testing/tools.txt b/docs/topics/testing/tools.txt index b9755305cb..1f794701be 100644 --- a/docs/topics/testing/tools.txt +++ b/docs/topics/testing/tools.txt @@ -984,18 +984,6 @@ The most straightforward way of creating a fixture is to use the already have some data in your database. See the :djadmin:`dumpdata documentation<dumpdata>` for more details. -.. note:: - - If you've ever run :djadmin:`manage.py migrate<migrate>`, you've - already used a fixture without even knowing it! When you call - :djadmin:`migrate` in the database for the first time, Django - installs a fixture called ``initial_data``. This gives you a way - of populating a new database with any initial data, such as a - default set of categories. - - Fixtures with other names can always be installed manually using - the :djadmin:`manage.py loaddata<loaddata>` command. - .. admonition:: Initial SQL data and testing Django provides a second way to insert initial data into models -- |