Bestehende migrations Dateien in ein anders Vz. verschieben

[Kirk]

Hallo
Ich suche für meine Style Changer EXT eine Möglichkeit die bestehenden migrations Dateien in ein anders Vz. verschieben so das es einem EXT Update zu keinerlei Fehlermeldung kommt.
Aktuell sind diese migrations Dateien im Vz. root/ext/kirk/stylechanger/migrations diese möchte in ein neues Vz. Namens v2x verschieben, der neue Pfad wäre dann root/ext/kirk/stylechanger/migrations/v2x
Hat jemand eine Idee wie man das sauber lösen könnte?

[Mike-on-Tour]

Ich weiß nicht, ob man das überhaupt sauber lösen könnte, denn außer der Verschiebung der Datei in ein anderes Verzeichnis müsste in jeder dieser Dateien der namespace-Eintrag geändert werden, was aber das geringste Problem ist.
Denn damit diese Dateien bei einer späteren Deaktivierung bzw. Re-Aktivierung auch ohne Probleme abgearbeitet werden können, müssen für alle diese Dateien die Einträge der Spalten migration_name und migration_depends_on in der MIGRATIONS_TABLE entsprechend geändert/ergänzt werden.
Ich hätte da ein schlechtes Gefühl dabei und wüsste jetzt auf Anhieb auch keine einfache Lösung dafür, weil das irgendwie einen Bruch in der Abarbeitung der Migrationsdateien darstellt.

[Crizzo]

Hi,

Ich denke außer die alte behalten, in der neuen die alte rückgängig machen und dann neu anwenden, wird es nicht gehen.

[Kirk]

Mike, da der Pfad in der DB eingetragen ist, hätte ich dabei auch ein schlechtes Gefühl.
Crizzo, diese Option hatte ich im Hinterkopf auch schon aber schnell wieder verworfen da mir dieses überhaupt zu sagte.
Als ich damals die erste migrations Datei erstellte, hatte man an sowas überhaupt nicht gedacht.

[LukeWCS]

Mahlzeit

Mike, an namespace hatte ich noch gar nicht gedacht. Ich hatte eine sehr "abenteuerliche" Methode im Sinn, bei der auch die Migrationskette intakt bleiben würde, aber die würde schon alleine wegen namespace gar nicht funktionieren.

Als ich damals die erste migrations Datei erstellte, hatte man an sowas überhaupt nicht gedacht.

Die phpBB Devs ebenfalls nicht. Und man ahnt ja nicht schon vorher, wie sich die weitere Entwicklung einer Ext noch gestalten würde.

Das Problem mit dem Migrator ist, dass die Migrationen - genau wie Sprachdateien - keine Daten-Dateien sind, sondern ausführbare Programme die zur Laufzeit inkludiert werden. Alleine dadurch hat man schon von vorneherein viel zu strikte (unflexible) Strukturen die einen nachhaltig bei Änderungen und Optimierungen behindern oder sogar effektiv blockieren. Wären Migrationen einfache Daten-Dateien, wäre eine nachträgliche Optimierung und sogar Komprimierung/Fusionierung der bestehenden Migrationen denkbar.

[Kirk]

Nun man kann nicht alles haben, hätte ja sein können das ich an irgendeine Möglichkeit gar nicht gedacht hatte.
Danke für eure Antworten