Ändern der Datenbank-Tabellen in Django

StackOverflow https://stackoverflow.com/questions/35991

  •  09-06-2019
  •  | 
  •  

Frage

Ich überlege mir, mit Django für ein Projekt bin ich ab (fyi, ein browser-basiertes Spiel) und eine der Funktionen, die ich mag die meisten ist mit syncdb das automatische erstellen der Datenbank-Tabellen basierend auf dem Django-Modelle, die ich definieren (eine Funktion, die ich kann nicht scheinen zu finden, in keinem anderen framework).Ich dachte schon, das war zu gut, um wahr zu sein, als ich das sah in der Dokumentation:

Syncdb nicht ändern bestehender Tabellen

syncdb wird nur das erstellen von Tabellen für Modelle, die noch nicht installiert wurden.Es wird nie eine Ausgabe ALTER TABLE-Anweisungen übereinstimmen änderungen an einem Modell der Klasse nach der installation.Änderungen an Modell-Klassen und Datenbank-schemas beinhalten Häufig eine form der Mehrdeutigkeit und in den Fällen, Django würde haben zu erraten, die richtigen änderungen zu machen.Es besteht die Gefahr, dass kritische Daten verloren gehen würden in den Prozess.

Wenn Sie änderungen vorgenommen haben, einem Modell ändern möchten, die Datenbank-Tabellen zu passen, verwenden Sie den sql-Befehl zur Anzeige des neuen SQL-Struktur und zu vergleichen, die zu Ihrem vorhandenen schema für die Tabelle um die änderungen.

Es scheint, dass die Veränderung der vorhandenen Tabellen noch getan werden muss "von hand".

Was ich gerne wissen würde ist der beste Weg, dies zu tun.Zwei Lösungen in den Sinn kommen:

  • Die Dokumentation schlägt vor, die änderungen manuell in der DB;
  • Ein backup der Datenbank ist, reinigen Sie es, erstellen Sie die Tabellen erneut (mit syncdb, da es nun das erstellen von Tabellen von Grund auf neu), und importieren Sie die gesicherten Daten (dies könnte zu lange dauern, wenn die Datenbank groß ist)

Irgendwelche Ideen?

War es hilfreich?

Lösung

Wie bereits in anderen Antworten auf die gleiche Thematik, achten Sie darauf, die DjangoCon 2008 Schema Evolution Panel auf YouTube.

Auch zwei neue Projekte auf der Karte: Simplemigrations und Zugvögel.

Andere Tipps

Manuell tun die SQL-änderungen und dump/reload sind die beiden Optionen, aber Sie können Sie auch prüfen wollen, einige der schema-evolution-Pakete für Django.Die meisten Reifen-Optionen sind django-evolution und South.

BEARBEITEN:Und hey, hier kommt dmigrations.

UPDATE:Da diese Antwort ursprünglich geschrieben wurde, django-evolution und dmigrations haben die beiden aufgehört, sich aktiv für die Entwicklung und South hat sich zum de-facto-standard für die schema-migration in Django.Teile von Süd kann auch integriert werden in Django innerhalb der nächsten release oder zwei.

UPDATE:Ein schema-Migrationen framework basiert auf südlich (und verfasst von Andrew Godwin, Autor von Süden) in Django 1.7+.

Ein guter Weg, dies zu tun ist über Einbauten, insbesondere die initial_data Leuchten.

Eine Vorrichtung ist eine Sammlung von Dateien, die den serialisierten Inhalt der Datenbank.Es ist also wie eine Sicherung der Datenbank, aber es ist etwas, Django ist sich bewusst, es ist einfacher zu bedienen und haben zusätzliche Vorteile, wenn Sie kommen, um Dinge wie unit-Tests.

Sie können eine fixture aus den Daten, die derzeit auf Ihrem DB mit django-admin.py dumpdata.Standardmäßig werden die Daten im JSON-format, aber auch andere Optionen, wie XML zur Verfügung stehen.Ein guter Ort, um Ladenbau ist eine fixtures sub-Verzeichnis Ihrer Anwendung directories.

Sie können das laden einer fixure mit django-admin.py loaddata aber deutlich mehr, wenn Ihr Gerät hat einen Namen, wie initial_data.json es wird automatisch geladen, wenn Sie eine syncdb, sparen Sie die Mühe der Import selbst.

Ein weiterer Vorteil ist, dass, wenn Sie laufen manage.py test zum ausführen von Unit-Tests der temporäre test-Datenbank werden auch die Ersten Daten der Leuchte geladen.

Natürlich wird diese Arbeit, wenn Sie beim hinzufügen von Attributen zu Modellen und Spalten, um die DB.Wenn Sie eine Spalte löschen aus der Datenbank, die Sie brauchen, um zu aktualisieren Sie Ihre Halterung zu entfernen, werden die Daten für diese Spalte, die möglicherweise nicht einfach.

Dies funktioniert am besten, wenn ich viele kleine änderungen an der Datenbank während der Entwicklung.Für die Aktualisierung Produktion DBs eine manuell generierte SQL-Skript kann funktionieren oft am besten.

Ich habe mit django-evolution.Vorsichtsmaßnahmen umfassen:

  • Seine automatische Vorschläge wurden einheitlich rotten;und
  • Seine fingerprint-Funktion gibt unterschiedliche Werte für die gleiche Datenbank auf verschiedenen Plattformen.

Das sagte, ich finde die benutzerdefinierte schema_evolution.py Ansatz praktisch.Arbeiten rund um das Fingerabdruck-problem, ich schlage vor, einen code wie:

BEFORE = 'fv1:-436177719' # first fingerprint
BEFORE64 = 'fv1:-108578349625146375' # same, but on 64-bit Linux
AFTER = 'fv1:-2132605944' 
AFTER64 = 'fv1:-3559032165562222486'

fingerprints = [
    BEFORE, AFTER,
    BEFORE64, AFTER64,
    ]

CHANGESQL = """
    /* put your SQL code to make the changes here */
    """

evolutions = [
    ((BEFORE, AFTER), CHANGESQL),
    ((BEFORE64, AFTER64), CHANGESQL)
    ]

Wenn ich hatte mehrere Fingerabdrücke und verändert, würde ich wieder-Faktor.Bis dahin, macht es sauberer wäre Diebstahl Entwicklung mal was anderes.

EDIT: Da bin ich manuell Bau meine änderungen sowieso, ich werde versuchen dmigrations nächsten Zeit.

django-Befehls-Erweiterungen ist eine django-Bibliothek gibt einige zusätzliche Befehle manage.py.Einer von Ihnen ist sqldiff, die sollte geben Sie die sql-Bedarf zu aktualisieren, um Ihr neues Modell.Es ist, jedoch, die 'experimentellen'.

So weit in meiner Firma haben wir die manuelle Methode.Was funktioniert am besten für Sie hängt sehr stark von der Entwicklung Stil.

Normalerweise haben wir nicht so viele schema-änderungen in der Produktion von Systemen und etwas formalisiert rollouts von der Entwicklung bis zur Produktion-Servern.Immer, wenn wir das roll-out (10-20 mal im Jahr) machen wir eine Füllung diff die aktuelle und die kommende Produktion Zweig überprüfen Sie den code, und stellt fest, was verändert werden muss, auf dem Produktions-server.Die erforderlichen änderungen werden möglicherweise zusätzliche Abhängigkeiten, änderungen an der settings Datei, und änderungen an der Datenbank.

Dies funktioniert sehr gut für uns.Nachdem das alles automatisiert ist, eine Nische vision, aber zu schwer für uns - vielleicht könnten wir verwalten Migrationen, aber wir noch brauchen würde, für die zusätzliche Bibliothek, server, unabhängig von Abhängigkeiten.

Django 1.7 (derzeit in Entwicklung) hinzufügen native Unterstützung für die schema-migration manage.py migrate und manage.py makemigrations (migrate deprecates syncdb).

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top