Wenn man eine Applikation installiert, ist es manchmal nützlich, wenn sie gleich die Datenbank mit ein paar fest vorgegebenen Datensätzen befüllt. Hierfür gibt es primär 2 Möglichkeiten in Django: Du kannst die Datenbank automatisch mit Fixtures oder mit Daten aus SQL-Statements befüllen.
In der Regel sind hierbei Fixtures die saubere Lösung, da sie nicht von einer bestimmten Datenbank abhängen. Daten aus SQL-Statements sind auf der anderen Seite aber flexibler.
Eine Fixture ist eine Sammlung von Daten, die Django in die Datenbank importieren kann. Wenn du bereits Daten in deiner Datenbank hast, kannst du so eine Fixture bestehend aus deinem aktuellen Datenbestand sehr einfach mit dem manage.py dumpdata-Befehl erstellen. Du kannst sie aber auch einfach händisch schreiben; in Form von XML-, YAML- oder JSON-Dokumenten. Die Serialisierungsdokumention bietet hierfür mehr Information über alle unterstützten Formate.
Trotzdem noch schnell eines kleines Beispiel für eine Fixture für Daten eines einfachen Person-Modells in JSON:
[
{
"model": "myapp.person",
"pk": 1,
"fields": {
"first_name": "John",
"last_name": "Lennon"
}
},
{
"model": "myapp.person",
"pk": 2,
"fields": {
"first_name": "Paul",
"last_name": "McCartney"
}
},
]
Und hier dieselbe Fixture in YAML:
- model: myapp.person
pk: 1
fields:
first_name: John
last_name: Lennon
- model: myapp.person
pk: 2
fields:
first_name: Paul
last_name: McCartney
Diese Datei speicherst du nun in einem fixtures-Ordner innerhalb deiner Applikation.
Daten in die Datenbank zu laden ist einfach: Führe einfach manage.py loaddata fixturename aus, wobei fixturename der Name deiner Fixtures-Datei ist. Jedes Mal wenn du loaddata aufrufst, werden die Daten aus deinen Fixtures gelesen und neu in die Datenbank geladen. Das heißt, solltest du eine der Zeilen, die durch ein Fixture erstellt wurden, ändern und loaddata erneut ausführen, werden deine Änderungen entfernt.
Wenn du eine Fixture mit dem Namen initial_data.[xml/yaml/json] erstellst, dann wird sie automatisch geladen, wenn du syncdb ausführst. Das ist zwar sehr nützlich, beachte aber bitte, dass diese Daten jedes Mal neu geladen werden, wenn du syncdb verwendest. Folglich solltest du initial_data nicht für Daten verwenden, die du vorhast, zu ändern.
Siehe auch
Fixtures werden auch vom Testing-Framework verwenden, um eine konsistente Testumgebung zu schaffen.
Django bietet auch einen Einstiegspunkt, um beliebige SQL-Statements gleich nach den CREATE TABLE-Statements bei syncdb auszuführen. Damit kannst du einerseits Basisdaten laden, oder auch SQL-Funktionen, Views, Trigger etc. erstellen.
Alles, was du tun musst, ist eine sql/<modelname>.sql in dem Verzeichnis deiner Applikation zu erstellen, wobei <modelname> der Name eines deiner Modelle kleingeschrieben darstellt.
Also wenn du ein Person-Modell in einer Applikation myapp hast, solltest du deine Statements in eine Datei mit dem Namen``sql/person.sql`` innerhalb deines myapp-Verzeichnisses speichern. Hier ein kleines Beispiel für eine solche Datei:
INSERT INTO myapp_person (first_name, last_name) VALUES ('John', 'Lennon');
INSERT INTO myapp_person (first_name, last_name) VALUES ('Paul', 'McCartney');
Jede solche SQL-Datei muss gültige SQL-Statements enthalten, welche die gewünschten Daten anlegen (zum Beispiel korrekt formatierte INSERT-Statements voneinander durch Semikolons getrennt).
Die SQL-Dateien werden von den Befehlen sqlcustom, sqlreset, sqlall und reset in manage.py gelesen. Mehr Information über manage.py findest du in der entsprechenden Dokumentation.
Bitte beachte, dass, solltest du mehrere SQL-Dateien haben, die Ordnung ihrer Abarbeitung nicht immer gleich sein muss. Du kannst lediglich davon ausgehen, dass die Tabellen für die entsprechenden Modelle bereits existieren, wenn deine SQL-Dateien geladen werden.
Wenn du SQL-Statements für bestimmten Datenbank-Backends wie PostgreSQL und MySQL verwenden möchtest, bietet dir Django auch hierfür eine Möglichkeit. So sucht Django speziell nach Dateien nach dem Muster <appname>/sql/<modelname>.<backend>.sql, wobei <appname> das Verzeichnis der jeweiligen Applikation, <modelname> der kleingeschriebene Name eines Modelles und <backend> der Wert der DATABASE_ENGINE-Einstellung (z.B. postgresql, mysql) in deiner Settings-Datei ist.
Backendspezifische SQL-Dateien werden vor den anderen SQL-Dateien geladen. Wenn deine Applikation zum Beispiel sowohl eine sql/person.sql- als auch eine sql/person.postgresql.sql-Datei hat und du die Applikation in PostgreSQL installierst, wird zunächst sql/person.postgresql.sql geladen und erst danach sql/person.postgresql.sql.
Mar 01, 2010