eine Verständnisfrage zu migrations

[Pitwheazle]

Also wenn ich das richtig she, wird bei jedem "..makemigrations" ein neuer Eintrag in "migrations" angelegt. Da sind bei mir schon einige Einträge zusammengekommen. Wenn ich das richtig sehe erkennt Django aber, wenn ich einen Eintrag ändere und die Änderung anschließend wieder zurücknehme und entfernt entsprechende Einträge. Frage: Was passiert, wenn ich diese ganzen Einträge in migrations lösche und dann erneut ...makemigrations ausführe - werden dann diese Einträge neu erstellt bzw. wird dann ein neuer Eintrag erstellt?

[sparrow]

makemigrations geht alle Migrationen der Apps im Projekt durch und errechnet daraus einen Status der Datenbank ("ist").
Dann geht es die Modelle der Apps durch.
Es wird dann je App eine Migration erstellt, die alle Änderungen beinhaltet um den Ist-Zustand zu ändern, dass der Zustand wie in den Modellen beschrieben ist.

[noisefloor]

Hallo,

1. Frage: was bewegt dich dazu zu erwägen, das eventuell machen zu wollen?

Ergänzend zu dem von sparrow gesagten: wenn die Datenbank zum Modell passt bricht die Migration ab, weil eben nix zu migrieren ist. Wenn deine Idee ist, alles in eine Migration zu packen - funktioniert so nicht. Die Migrationsdateien sind auch noch Python Dateien mit Listen, Wörterbücher etc. Man kann die also von Hand bearbeiten und auch Migrationen von Hand anlegen. Ist auch in der Django-Doku erklärt. Würde ich an deiner Stelle aber sehr sicher nicht in Erwägung ziehen.

Gruß, noisefoor

[Pitwheazle]

Das heiß: ja? (wenn ich alle migrations lösche, stellt makemigrations fest dass der ist-Zustand nicht mit den Modellen übereinstimmt und erstellt eine Migration in der alle Änderungen, besser alle Vorgaben in models.py drinstehen)?

[Pitwheazle]

1. Frage: was bewegt dich dazu zu erwägen, das eventuell machen zu wollen?

Nun ja, einserseits habe ich immer wieder Änderungen in den Modellen vorgenommen und wieder rückgängig gemacht. Nach der Erklärung von @sparrow erkennt das Django aber selbst - wenn ich das richtig verstanden habe.
Dann habe ich aber auch festgestellt, dass meine Einträge in migrations in meinem lokal gespeicherten Projekt nicht hundertprozentig mit denen auf dem Server im Internet übereinstimmen und das ergibt Fehler, wenn ich auf dem Internetserver Makemigrations ausführe (jetzt schimpft ihr wieder, dass mein Development Pfusch ist - das lerne ich ja aber vielleicht auch noch). So lade ich jetzt halt im Zweifelsfalle meine Datenbank aus dem Internet runter, mache die Änderungen und lade sie wieder hoch. (Auweh, da bekomme ich jetzt wieder Geschimpftes! - irgendwann finde ich ja vielleicht einen Administrator der das ordentlich macht - ich bin dran).
Zurück zur Frage: Ich versuche halt auch immer mehr von Django zu verstehen und @sprrow hat mich da ja wieder ein kleines Stückchen weitergebracht. Danke!

[sparrow]

Das, was du dir vorstellst, wird nicht funktionieren.
Wenn deine Migrationen zwischen den Systemen unterschiedlich sind, dann hast du schon einen großen Bock geschossen. Den heilst du nicht, indem du die Migrations löscht.
Dann hat du je App eine große Migration - aber eine Datenbank die denkt, dass x Migrationen bereits eingespielt sind.

Migrationen gehören ins Repository. Und "makemigrations" macht man in der Entwicklungsumgebung und führt auf dem Produktivsystem nur "migrate" aus.

[noisefloor]

Hallo,

vergiß' es einfach, dass das ein Weg sein könnte. Grund: siehe Post von sparrow. Es würde deine Problemliste nur um +1 verlängern.

"Release often, release early" ist zwar ein ein altes Open Source Software Credo - aber das ist auch nicht immer gut. Manchmal muss man halt Geduld haben, um ready for production zu sein.

Gruß, noisefloor

[nezzcarth]

Es stimmt, dass du pro models.py neue Migrations erhältst, wenn du alle bisherigen löschst und makemigrations ausführst. Das ist aber nur dann unkritisch, wenn du mit einer frischen, leeren Datenbank von vorne beginnen möchtest. Die Migrations existieren nicht nur als Python Dateien sondern bei Projekten, die bereits über eine funktionierende Datenbank verfügen, gibt es für sie auch als Einträge in einer Datenbanktabelle. Du müsstest also da auch Änderungen durchführen, damit das Projekt funktionsfähig bleibt. Und das ist dann ein Ausmaß an Eingriffen, das man, wenn es geht, eher vermeiden möchte.

Wie die anderen schon meinten, ist das keine Lösung für dein Problem.

Dann habe ich aber auch festgestellt, dass meine Einträge in migrations in meinem lokal gespeicherten Projekt nicht hundertprozentig mit denen auf dem Server im Internet übereinstimmen und das ergibt Fehler, wenn ich auf dem Internetserver Makemigrations ausführe (jetzt schimpft ihr wieder, dass mein Development Pfusch ist - das lerne ich ja aber vielleicht auch noch).

Verwendest du denn keine einheitliche Versionskontrolle?

[Pitwheazle]

Ich versuche halt auch immer mehr von Django zu verstehen und @sparrow hat mich da ja wieder ein kleines Stückchen weitergebracht. Danke!

Und damit verstehe ich vielleicht auch wieder ein bisschen mehr:

Migrationen gehören ins Repository. Und "makemigrations" macht man in der Entwicklungsumgebung und führt auf dem Produktivsystem nur "migrate" aus.

Verwendest du denn keine einheitliche Versionskontrolle?

Tja, das muss man halt erstmal lernen!
Also ich fasse mal zusammen:
Da es mir, mit eurer Hilfe jetzt, glaube ich, gelungen ist, in Github eine ordentliche Version meines Rechentrainers zu speichern, müsste ich es jetzt als nächstes hinbekommen, damit mein Projekt in uberspace zu synchronisieren. Bisher habe ich ja, wie beschrieben, immer nur einzelne Dateien mittels Filezilla hochgeladen und musste mir sagen lassen, dass das nicht der richtige Weg ist. Wäre es denn richtig, mein Projekt mit Github zu synchronisieren, meinen gunicorn Server auf uberspace zu stoppen und dann den ganzen Ordner komplett hochzuladen? Wen ich makemigrations auf meinem Produktionssystem ausführe, werden damit auch die migrations hochgeladen.
Und die, an anderer Stelle erwähnte, Datei rt_dev@.service entferne ich dort?
Aber nochmals zurück zu meiner Ursprungsfrage. ich hatte ja eigentlich gedacht, wenn ich Änderungen in einem Modell vornehme und später wieder zurücknehme, werden diese, m.E. überflüssigen, migrations entfernt. Werden sie aber nicht, ich habe in der falschen App nachgeschaut. Kann ich die beiden löschen?

[sparrow]

Nein.
Es können auch nicht autmagisch irgendwelche Migrationen wieder entfernt werden. Wie soll das funktionieren?

Nummern spielen bei Migrationen eigentlich keine Rolle, weil der Abhängigkeitsbaum ohne auskommt, der Einfachheit halber nehmen wir sie hier aber so, wie Django sie anlegt.

Du hast eine Migration 010, die eine Spalte zu einer Relation hinzufügt.
Du hast eine Migration 020, die die Spalte aus Migration 010 wieder entfernt

Jetzt hast du ein System, auf dem alle Migrationen bis 015 eingespielt sind.
Wenn sich jetzt 010 und 020 aufheben und - wie du dachtest beobachtet zu haben - einfach löschen (oder du tust)... wie genau soll denn jetzt das System, auf dem die Migrationen bis 015 eingespielt sind bemerken, dass die Spalte entfernt wurde? Bemerkt es, wenn irgendwann an 020 vorbei migriert wird.
Deshalb sind Migrationen nie überflüssig.
Deshalb ist es gefährlich in den Migrationsdateien zu editieren, wenn man nicht weiß, was da genau passiert.

[noisefloor]

Hallo,

ich hatte ja eigentlich gedacht, wenn ich Änderungen in einem Modell vornehme und später wieder zurücknehme, werden diese, m.E. überflüssigen, migrations entfernt. Werden sie aber nicht, ich habe in der falschen App nachgeschaut. Kann ich die beiden löschen?

Nein, du hast du auch einen Denkfehler drin. Sieh' Migrations wie ein Logbuch, das den Verlauf darstellt. Der Verlauf ist halt real und bedingt eine Veränderung an der Datenbank. Auch, wenn du am Ende vielleicht wieder beim gleiche Modell wie vor X Migrationen bist.
Das kannst du dir auch so vorstellen, als stündest auf Punkt A, gehst 3 Schritte nach links, 6 nach rechts, wieder 3 nach links. Dann stehst du wieder auf A, hast dich aber trotzdem bewegt. Was du vorhast wäre den Bewegungsprofil zu löschen und zu sagen "ich habe mich nicht bewegt". Hast du aber faktisch.

Noch nochmal die Frage: warum? Es löst _keines_ deiner Problem, wenn du händisch in den Migrationen rum fummelst. Und du hast definitiv genug andere Problem.

Gruß, noisefloor

[grubenfox]

... und hier passt etwas nicht zusammen:

Und damit verstehe ich vielleicht auch wieder ein bisschen mehr:

Migrationen gehören ins Repository. Und "makemigrations" macht man in der Entwicklungsumgebung und führt auf dem Produktivsystem nur "migrate" aus.

... Wäre es denn richtig, mein Projekt mit Github zu synchronisieren, meinen gunicorn Server auf uberspace zu stoppen und dann den ganzen Ordner komplett hochzuladen? Wen ich makemigrations auf meinem Produktionssystem ausführe, werden damit auch die migrations hochgeladen.

...auf dem Produktivsystem nur "migrate" ... hatte sparrow geschrieben

[Pitwheazle]

OK, stimmt.

[nezzcarth]

Wäre es denn richtig, mein Projekt mit Github zu synchronisieren, meinen gunicorn Server auf uberspace zu stoppen und dann den ganzen Ordner komplett hochzuladen?

Also ich hoffe, ich habe das jetzt alles richtig verstanden, aber eigentlich hast du doch schon alles, um es komplett über Git abzuwickeln, ohne umständlich mit FTP Ordner rumzukopieren. Wenn der Rechentrainer eh schon frei auf Github liegt, brauchst du halt einmal lokal eine Arbeitskopie, sowie auf dem Uberspace eine weitere, die für das Deployment da ist. Gibt es eine Änderung, pushst die von Lokal nach Github. Anschließend loggst du dich per SSH auf deinem Uberspace ein, pullst da und fertig (das ist die Grundstruktur; normalerweise zieht man es etwas komplexer auf bzw. kann auch vieles automatisieren, aber das ist vielleicht eher was für später). Dann gibt es auch keine Probleme mit Dateien die asynchron sind oder Dateien, die da sind, aber nicht da sein sollten. Wichtig ist halt nur, dass der Code so aufgebaut ist, dass Passwörter und so etwas sauber getrennt und losgelöst von Git hinterlegt sind; ich glaube, bei dir sind aber sogar die kompletten Settings, wenn ich das richtig gesehen habe, nicht im Git.

[Pitwheazle]

OK, prima - dann mache ich mich mal dran, rauszubekommen wie man das macht. Im Manual von uber finde ich dazu auf den ersten Blick nichts. Muss ich git in uber installieren? Ich stoppe also gunicorn, pulle mein Projekt aus github, alle alten Dateien werden überschrieben, neue ergänzt, settings und Datenbank bleiben erhalten, ich führe u.U. migrate aus und starte den Server wieder. So hätte ich mir das vorgestellt.
Euch allen wieder mal vielen Dank für eure endlose geduld mit meiner Begriffsstutzigkeit. In diesem Posting habe ich soviel gelernt wie noch in keinem anderen!
Vielleicht verstehe ich irgendwann auch noch das objektorientierte Programmieren
Übrigens habe ich das Problem mit den komplementären migrations doch noch hinbekommen. Ich habe ja schließlich Git und kann die letzten Schritte rückgängig machen.

[sparrow]

Wenn du die Migrationen bereits eingespielt hast, nützt das nichts.
Dann ist es ja ebenso wie löschen.

[Pitwheazle]

Ich habe ein Kopie der Datenbank vor dem makemigrations

[Pitwheazle]

... aber trotzdem Danke für den Hinweis, dass macht es auch wieder einfacher mit dem Verständnis!