From 67235fd4ef1b006fc9cdb2fa20e7bb93b0edff4b Mon Sep 17 00:00:00 2001 From: Tim Graham Date: Fri, 26 Dec 2014 13:23:38 -0500 Subject: Removed support for initial_data fixtures per deprecation timeline. --- docs/howto/initial-data.txt | 15 --------------- docs/ref/django-admin.txt | 6 ------ docs/topics/testing/overview.txt | 5 ----- docs/topics/testing/tools.txt | 12 ------------ 4 files changed, 38 deletions(-) (limited to 'docs') 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 `. - -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` for more details. -.. note:: - - If you've ever run :djadmin:`manage.py 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` command. - .. admonition:: Initial SQL data and testing Django provides a second way to insert initial data into models -- -- cgit v1.3