mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2025-07-24 13:44:32 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 4

Removed support for initial_data fixtures per deprecation timeline.

Browse source
This commit is contained in:
Tim Graham 2014-12-26 13:23:38 -05:00
parent f635d75935
commit 67235fd4ef
21 changed files with 22 additions and 241 deletions
Download patch file Download diff file Expand all files Collapse all files

15
docs/howto/initial-data.txt
View file

@ -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
--------------------------------

6
docs/ref/django-admin.txt
View file

@ -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
---------

5
docs/topics/testing/overview.txt
View file

@ -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.

12
docs/topics/testing/tools.txt
View file

@ -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 --