initial-data.txt 3.1 KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788899091929394959697
  1. ======================================
  2. How to provide initial data for models
  3. ======================================
  4. It's sometimes useful to pre-populate your database with hard-coded data when
  5. you're first setting up an app. You can provide initial data with migrations or
  6. fixtures.
  7. Providing initial data with migrations
  8. ======================================
  9. If you want to automatically load initial data for an app, create a
  10. :ref:`data migration <data-migrations>`. Migrations are run when setting up the
  11. test database, so the data will be available there, subject to :ref:`some
  12. limitations <test-case-serialized-rollback>`.
  13. .. _initial-data-via-fixtures:
  14. Providing data with fixtures
  15. ============================
  16. You can also provide data using fixtures, however, this data isn't loaded
  17. automatically, except if you use :attr:`.TransactionTestCase.fixtures`.
  18. A fixture is a collection of data that Django knows how to import into a
  19. database. The most straightforward way of creating a fixture if you've already
  20. got some data is to use the :djadmin:`manage.py dumpdata <dumpdata>` command.
  21. Or, you can write fixtures by hand; fixtures can be written as JSON, XML or YAML
  22. (with PyYAML_ installed) documents. The :doc:`serialization documentation
  23. </topics/serialization>` has more details about each of these supported
  24. :ref:`serialization formats <serialization-formats>`.
  25. .. _PyYAML: https://pyyaml.org/
  26. As an example, though, here's what a fixture for a ``Person`` model might look
  27. like in JSON:
  28. .. code-block:: js
  29. [
  30. {
  31. "model": "myapp.person",
  32. "pk": 1,
  33. "fields": {
  34. "first_name": "John",
  35. "last_name": "Lennon"
  36. }
  37. },
  38. {
  39. "model": "myapp.person",
  40. "pk": 2,
  41. "fields": {
  42. "first_name": "Paul",
  43. "last_name": "McCartney"
  44. }
  45. }
  46. ]
  47. And here's that same fixture as YAML:
  48. .. code-block:: yaml
  49. - model: myapp.person
  50. pk: 1
  51. fields:
  52. first_name: John
  53. last_name: Lennon
  54. - model: myapp.person
  55. pk: 2
  56. fields:
  57. first_name: Paul
  58. last_name: McCartney
  59. You'll store this data in a ``fixtures`` directory inside your app.
  60. You can load data by calling :djadmin:`manage.py loaddata <loaddata>`
  61. ``<fixturename>``, where ``<fixturename>`` is the name of the fixture file
  62. you've created. Each time you run :djadmin:`loaddata`, the data will be read
  63. from the fixture and re-loaded into the database. Note this means that if you
  64. change one of the rows created by a fixture and then run :djadmin:`loaddata`
  65. again, you'll wipe out any changes you've made.
  66. Where Django finds fixture files
  67. --------------------------------
  68. By default, Django looks in the ``fixtures`` directory inside each app for
  69. fixtures. You can set the :setting:`FIXTURE_DIRS` setting to a list of
  70. additional directories where Django should look.
  71. When running :djadmin:`manage.py loaddata <loaddata>`, you can also
  72. specify a path to a fixture file, which overrides searching the usual
  73. directories.
  74. .. seealso::
  75. Fixtures are also used by the :ref:`testing framework
  76. <topics-testing-fixtures>` to help set up a consistent test environment.