initial-data.txt 3.8 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110
  1. ======================================
  2. How to provide initial data for models
  3. ======================================
  4. It's sometimes useful to prepopulate 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. Provide initial data with migrations
  8. ====================================
  9. 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. Provide 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 reloaded 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. Tell Django where to look for fixture files
  67. -------------------------------------------
  68. By default, Django looks for fixtures in the ``fixtures`` directory inside each
  69. app for, so the command ``loaddata sample`` will find the file
  70. ``my_app/fixtures/sample.json``. This works with relative paths as well, so
  71. ``loaddata my_app/sample`` will find the file
  72. ``my_app/fixtures/my_app/sample.json``.
  73. Django also looks for fixtures in the list of directories provided in the
  74. :setting:`FIXTURE_DIRS` setting.
  75. To completely prevent default search form happening, use an absolute path to
  76. specify the location of your fixture file, e.g. ``loaddata /path/to/sample``.
  77. .. admonition:: Namespace your fixture files
  78. Django will use the first fixture file it finds whose name matches, so if
  79. you have fixture files with the same name in different applications, you
  80. will be unable to distinguish between them in your ``loaddata`` commands.
  81. The easiest way to avoid this problem is by *namespacing* your fixture
  82. files. That is, by putting them inside a directory named for their
  83. application, as in the relative path example above.
  84. .. seealso::
  85. Fixtures are also used by the :ref:`testing framework
  86. <topics-testing-fixtures>` to help set up a consistent test environment.