Hallo. EE 7.1 Weiss jemand, wie man migrations ausserhalb von source verzeichnis pflegt, so dass sie mit console-command dann ausgeführt werden können?
Am besten will ich dass bei :migrate die Migrations die in projectroot/migrations/data liegen mit ausgeführt werden.
Danke und ein schönes WE.
Das habe ich hinbekommen. Allerdings bin ich oxid migrations umgangen und mit plain doctrine migrations generiert. Macht das jemand auch so? Oder Ihr nutzt alle oxmigrations_ce/pe/ee Tabellen auch für custom migrations die ausserhalb des Installations-Prozesses generiert und ausgeführt werden?
Du kannst die Migrations für jedes Modul separat aufrufen, indem Du dem Command die modul-ID mitgibst. In welche Datenbank-Tabelle die Historie geschrieben wird, ist ja nur eine Einstellungssache in der Konfiguration. Der Übersichtlichkeit halber verwende ich pro Modul jeweils eine eigene Tabelle. Ohne Angabe einer Suite werden der Reihe nach die Shop-Migrationen und dann alle Modulmigrationen durchlaufen.
Als Basis dient meiner Entwicklung die OXID-Erweiterung der Migrations. Die hat zwar durchaus Nachteile (z.B. keine Down-Migration und keine Migration auf eine spezielle Version), ist jedoch so am ehesten im Standardablauf integriert.
Vanilla Doctrine funktioniert für ein einzelnes Modul mit den entsprechenden Konfigurationsparametern ebenfalls. Du musst dann jedoch eine Konfigurationsdatei für die Datenbank mitgeben. In Verbindung mit den Shopmigrationen dürfte das vermutlich aber nicht funktionieren.
Hallo Daniel, vielen Dank für die ausführliche Antwort.
Mein Usecase ist noch spezifischer, ich muss über Migrationen Rollen und Rechte erstellen.
Und zwar das muss dann in die CI pipeline rein, so dass alle Shop Instanzen (lokal, dev stage, prod) die automatisch ausführen.
Ich habe mich also entschlossen, diese “Rollenerstellungsmigrationen” an KEIN Modul zu binden, sondern von etweigen Modulen zu entkoppeln. Die Idee ist, die werden immer beim Shop Setup ZULETZT ausgeführt und gut ist. Als historie - Tabelle nutze ich dann die von vanilla Doctrine angelegte Standarttabelle.`
ps. Habe eine migrate.php Datei erstellt, die doctrine cli zur Verf. stellt um dann über
docker exec -ti oxid-php-1 php migrate.php migrations:migrate
auszuführen, klappt soweit.
Wäre so eine Architektur Deiner Meinung nach tragbar?
Ohne Details zu kennen klingt das nach einer projektspezifischen Umsetzung. Da ist alles i.O., was zuverlässig läuft. Daher scheint das passend zu sein.
In meinen Fällen habe ich eher Module im Blick, die auch ohne den ursprünglichen Entwickler in jedem Fall zuverlässig laufen müssen. Da vermeide ich alle Sonderwege.
Danke, passt sowet!