It’s sometimes useful to pre-populate your database with hard-coded data when\nyou’re first setting up an app. There’s a couple of ways you can have Django\nautomatically create this data: you can provide initial data via fixtures, or\nyou can provide initial data as SQL.
\nIn general, using a fixture is a cleaner method since it’s database-agnostic,\nbut initial SQL is also quite a bit more flexible.
\nA fixture is a collection of data that Django knows how to import into a\ndatabase. The most straightforward way of creating a fixture if you’ve already\ngot some data is to use the manage.py dumpdata command.\nOr, you can write fixtures by hand; fixtures can be written as JSON, XML or YAML\n(with PyYAML installed) documents. The serialization documentation has more details about each of these supported\nserialization formats.
As an example, though, here’s what a fixture for a simple Person model might\nlook like in JSON:
[\n {\n "model": "myapp.person",\n "pk": 1,\n "fields": {\n "first_name": "John",\n "last_name": "Lennon"\n }\n },\n {\n "model": "myapp.person",\n "pk": 2,\n "fields": {\n "first_name": "Paul",\n "last_name": "McCartney"\n }\n }\n]\nAnd here’s that same fixture as YAML:
\n- model: myapp.person\n pk: 1\n fields:\n first_name: John\n last_name: Lennon\n- model: myapp.person\n pk: 2\n fields:\n first_name: Paul\n last_name: McCartney\nYou’ll store this data in a fixtures directory inside your app.
Loading data is easy: just call manage.py loaddata\n<fixturename>, where <fixturename> is the name of the fixture file\nyou’ve created. Each time you run loaddata, the data will be read\nfrom the fixture and re-loaded into the database. Note this means that if you\nchange one of the rows created by a fixture and then run loaddata\nagain, you’ll wipe out any changes you’ve made.
If you create a fixture named initial_data.[xml/yaml/json], that fixture will\nbe loaded every time you run migrate. This is extremely convenient,\nbut be careful: remember that the data will be refreshed every time you run\nmigrate. So don’t use initial_data for data you’ll want to edit.
By default, Django looks in the fixtures directory inside each app for\nfixtures. You can set the FIXTURE_DIRS setting to a list of\nadditional directories where Django should look.
When running manage.py loaddata, you can also\nspecify a path to a fixture file, which overrides searching the usual\ndirectories.
Django provides a hook for passing the database arbitrary SQL that’s executed\njust after the CREATE TABLE statements when you run migrate. You can\nuse this hook to populate default records, or you could also create SQL\nfunctions, views, triggers, etc.
The hook is simple: Django just looks for a file called sql/<modelname>.sql,\nin your app directory, where <modelname> is the model’s name in lowercase.
So, if you had a Person model in an app called myapp, you could add\narbitrary SQL to the file sql/person.sql inside your myapp directory.\nHere’s an example of what the file might contain:
INSERT INTO myapp_person (first_name, last_name) VALUES ('John', 'Lennon');\nINSERT INTO myapp_person (first_name, last_name) VALUES ('Paul', 'McCartney');\nEach SQL file, if given, is expected to contain valid SQL statements\nwhich will insert the desired data (e.g., properly-formatted\nINSERT statements separated by semicolons).
The SQL files are read by the sqlcustom and sqlall\ncommands in manage.py. Refer to the manage.py\ndocumentation for more information.
Note that if you have multiple SQL data files, there’s no guarantee of\nthe order in which they’re executed. The only thing you can assume is\nthat, by the time your custom data files are executed, all the\ndatabase tables already will have been created.
\n\nThere’s also a hook for backend-specific SQL data. For example, you\ncan have separate initial-data files for PostgreSQL and SQLite. For\neach app, Django looks for a file called\n<app_label>/sql/<modelname>.<backend>.sql, where <app_label> is\nyour app directory, <modelname> is the model’s name in lowercase\nand <backend> is the last part of the module name provided for the\nENGINE in your settings file (e.g., if you have\ndefined a database with an ENGINE value of\ndjango.db.backends.sqlite3, Django will look for\n<app_label>/sql/<modelname>.sqlite3.sql).
Backend-specific SQL data is executed before non-backend-specific SQL\ndata. For example, if your app contains the files sql/person.sql\nand sql/person.sqlite3.sql and you’re installing the app on\nSQLite, Django will execute the contents of\nsql/person.sqlite3.sql first, then sql/person.sql.