A fixture is a collection of files that contain the serialized contents of\nthe database. Each fixture has a unique name, and the files that comprise the\nfixture can be distributed over multiple directories, in multiple applications.
\n\nFixtures can be generated by manage.py dumpdata. It’s\nalso possible to generate custom fixtures by directly using serialization\ntools or even by handwriting them.
Fixtures can be used to pre-populate the database with data for\ntests:
\nclass MyTestCase(TestCase):\n fixtures = ["fixture-label"]\nor to provide some initial data using the\nloaddata command:
django-admin loaddata <fixture label>\nDjango will search in these locations for fixtures:
\nIn the fixtures directory of every installed application
In any directory listed in the FIXTURE_DIRS setting
In the literal path named by the fixture
Django will load any and all fixtures it finds in these locations that match\nthe provided fixture names. If the named fixture has a file extension, only\nfixtures of that type will be loaded. For example:
\ndjango-admin loaddata mydata.json\nwould only load JSON fixtures called mydata. The fixture extension must\ncorrespond to the registered name of a\nserializer (e.g., json or xml).
If you omit the extensions, Django will search all available fixture types for\na matching fixture. For example:
\ndjango-admin loaddata mydata\nwould look for any fixture of any fixture type called mydata. If a fixture\ndirectory contained mydata.json, that fixture would be loaded as a JSON\nfixture.
The fixtures that are named can include directory components. These directories\nwill be included in the search path. For example:
\ndjango-admin loaddata foo/bar/mydata.json\nwould search <app_label>/fixtures/foo/bar/mydata.json for each installed\napplication, <dirname>/foo/bar/mydata.json for each directory in\nFIXTURE_DIRS, and the literal path foo/bar/mydata.json.
Multiple fixtures can be specified in the same invocation. For example:
\ndjango-admin loaddata mammals birds insects\nor in a test case class:
\nclass AnimalTestCase(TestCase):\n fixtures = ["mammals", "birds", "insects"]\nThe order in which fixtures are loaded follows the order in which they are\nlisted, whether it’s when using the management command or when listing them in\nthe test case class as shown above.
\nIn these examples, all the fixtures named mammals from all applications (in\nthe order in which applications are defined in INSTALLED_APPS) will\nbe loaded first. Subsequently, all the birds fixtures will be loaded,\nfollowed by all the insects fixtures.
Be aware that if the database backend supports row-level constraints, these\nconstraints will be checked at the end of the transaction. Any relationships\nacross fixtures may result in a load error if the database configuration does\nnot support deferred constraint checking (refer to the MySQL docs for an\nexample).
\nWhen fixture files are processed, the data is saved to the database as is.\nModel defined save() methods are not called, and\nany pre_save or\npost_save signals will be called with\nraw=True since the instance only contains attributes that are local to the\nmodel. You may, for example, want to disable handlers that access\nrelated fields that aren’t present during fixture loading and would otherwise\nraise an exception:
from django.db.models.signals import post_save\nfrom .models import MyModel\n\n\ndef my_handler(**kwargs):\n # disable the handler during fixture loading\n if kwargs["raw"]:\n return\n ...\n\n\npost_save.connect(my_handler, sender=MyModel)\nYou could also write a decorator to encapsulate this logic:
\nfrom functools import wraps\n\n\ndef disable_for_loaddata(signal_handler):\n """\n Decorator that turns off signal handlers when loading fixture data.\n """\n\n @wraps(signal_handler)\n def wrapper(*args, **kwargs):\n if kwargs["raw"]:\n return\n signal_handler(*args, **kwargs)\n\n return wrapper\n\n\n@disable_for_loaddata\ndef my_handler(**kwargs): ...\nJust be aware that this logic will disable the signals whenever fixtures are\ndeserialized, not just during loaddata.
Fixtures may be compressed in zip, gz, bz2, lzma, or xz\nformat. For example:
django-admin loaddata mydata.json\nwould look for any of mydata.json, mydata.json.zip, mydata.json.gz,\nmydata.json.bz2, mydata.json.lzma, or mydata.json.xz. The first\nfile contained within a compressed archive is used.
Note that if two fixtures with the same name but different fixture type are\ndiscovered (for example, if mydata.json and mydata.xml.gz were found in\nthe same fixture directory), fixture installation will be aborted, and any data\ninstalled in the call to loaddata will be removed from the database.
If you’re in a multi-database setup, you might have fixture data that\nyou want to load onto one database, but not onto another. In this\nsituation, you can add a database identifier into the names of your fixtures.
\nFor example, if your DATABASES setting has a users database\ndefined, name the fixture mydata.users.json or\nmydata.users.json.gz and the fixture will only be loaded when you\nspecify you want to load data into the users database.