mirror of
				https://github.com/django/django.git
				synced 2025-11-03 21:25:09 +00:00 
			
		
		
		
	
		
			
				
	
	
		
			85 lines
		
	
	
	
		
			2.6 KiB
		
	
	
	
		
			Text
		
	
	
	
	
	
			
		
		
	
	
			85 lines
		
	
	
	
		
			2.6 KiB
		
	
	
	
		
			Text
		
	
	
	
	
	
=================================
 | 
						|
Providing initial data for models
 | 
						|
=================================
 | 
						|
 | 
						|
It's sometimes useful to pre-populate your database with hard-coded data when
 | 
						|
you're first setting up an app. You can provide initial data via fixtures.
 | 
						|
 | 
						|
.. _initial-data-via-fixtures:
 | 
						|
 | 
						|
Providing initial data with fixtures
 | 
						|
====================================
 | 
						|
 | 
						|
A fixture is a collection of data that Django knows how to import into a
 | 
						|
database. The most straightforward way of creating a fixture if you've already
 | 
						|
got some data is to use the :djadmin:`manage.py dumpdata <dumpdata>` command.
 | 
						|
Or, you can write fixtures by hand; fixtures can be written as JSON, XML or YAML
 | 
						|
(with PyYAML_ installed) documents. The :doc:`serialization documentation
 | 
						|
</topics/serialization>` has more details about each of these supported
 | 
						|
:ref:`serialization formats <serialization-formats>`.
 | 
						|
 | 
						|
.. _PyYAML: http://www.pyyaml.org/
 | 
						|
 | 
						|
As an example, though, here's what a fixture for a simple ``Person`` model might
 | 
						|
look like in JSON:
 | 
						|
 | 
						|
.. code-block:: js
 | 
						|
 | 
						|
    [
 | 
						|
      {
 | 
						|
        "model": "myapp.person",
 | 
						|
        "pk": 1,
 | 
						|
        "fields": {
 | 
						|
          "first_name": "John",
 | 
						|
          "last_name": "Lennon"
 | 
						|
        }
 | 
						|
      },
 | 
						|
      {
 | 
						|
        "model": "myapp.person",
 | 
						|
        "pk": 2,
 | 
						|
        "fields": {
 | 
						|
          "first_name": "Paul",
 | 
						|
          "last_name": "McCartney"
 | 
						|
        }
 | 
						|
      }
 | 
						|
    ]
 | 
						|
 | 
						|
And here's that same fixture as YAML:
 | 
						|
 | 
						|
.. code-block:: none
 | 
						|
 | 
						|
    - model: myapp.person
 | 
						|
      pk: 1
 | 
						|
      fields:
 | 
						|
        first_name: John
 | 
						|
        last_name: Lennon
 | 
						|
    - model: myapp.person
 | 
						|
      pk: 2
 | 
						|
      fields:
 | 
						|
        first_name: Paul
 | 
						|
        last_name: McCartney
 | 
						|
 | 
						|
You'll store this data in a ``fixtures`` directory inside your app.
 | 
						|
 | 
						|
Loading data is easy: just call :djadmin:`manage.py loaddata <loaddata>`
 | 
						|
``<fixturename>``, where ``<fixturename>`` is the name of the fixture file
 | 
						|
you've created. Each time you run :djadmin:`loaddata`, the data will be read
 | 
						|
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.
 | 
						|
 | 
						|
Where Django finds fixture files
 | 
						|
--------------------------------
 | 
						|
 | 
						|
By default, Django looks in the ``fixtures`` directory inside each app for
 | 
						|
fixtures. You can set the :setting:`FIXTURE_DIRS` setting to a list of
 | 
						|
additional directories where Django should look.
 | 
						|
 | 
						|
When running :djadmin:`manage.py loaddata <loaddata>`, you can also
 | 
						|
specify a path to a fixture file, which overrides searching the usual
 | 
						|
directories.
 | 
						|
 | 
						|
.. seealso::
 | 
						|
 | 
						|
    Fixtures are also used by the :ref:`testing framework
 | 
						|
    <topics-testing-fixtures>` to help set up a consistent test environment.
 |