ich nutze in meinen Modulen für die Erweiterung (bzw. Rückbau) der Datenbank während der Aktivierung (bzw. Deaktivierung) der Module die Events onActivate (bzw. onDeactivate).
Nun will ich meine eigenen Datenbank-Erweiterungen erweitern.
Ich könnte nun bei jeder Erweiterung meiner Module die Methoden onActivate und onDeactivate wiederum erweitern und jeweils neben den initialen SQLs noch Erweiterungs-SQLs ergänzen. Das macht aber meine beiden Methoden mit der Zeit immer unübersichtlicher und schwerer nachvollziehbar.
Da gefallen mir die Mechaniken für die Shop-Migrationen: https://docs.oxid-esales.com/developer/en/6.1/oxid_components/migrations.html
Dort kann ich für jeden Migrationsfall eine neue PHP-Migrations-Rumpfdatei angelegen, die ich wiederum individuell befüllen kann. Das Ergebnis ist dann sehr gut nachvollziehbar.
Die Shop-Migrationen eignen sich allerdings nicht für allgemein anzuwendenene, shopunabhängige Modul-Migrationen.
Wie löst Ihr das Problem? Ich wäre an einer auf PHP-basierenden Lösung interessiert (also nicht ein abarbeiten von separaten SQL-Dateien). Denn ich will in den PHP-Dateien noch Bedingungen prüfen, die ich nicht in SQLs verlagern kann. Also eine ähnliche Modul-Migrations-Lösung so wie sie für den Shop existiert (s.o.).
Danke!
P.S: Ich wünsch Euch allen ein erfolgreiches neues OXID-Jahr
Tun sie das wirklich? Ich kenne nur das hier, da hab ich mit Alfred darüber diskutiert, das in der Oxid Console zu unterstützen… https://github.com/OXIDprojects/oxid-console/issues/22 Aber im OXID “Core” wäre das natürlich noch besser …
Mittels vendor/bin/oe-eshop-db_migrate migrations:generate PR lassen sich diese erstellen, können aber auch manuell im entsprechenden Ordner abgelegt werden. Der CI/CD Job ruft dann entsprechend vendor/bin/oe-eshop-db_migrate migrations:migrate auf, sodass die Projekt-Migrationen am Ende (nach CE, PE, EE) ausgeführt und in der DB entsprechend eingetragen werden.
@JCT: Die Lösung von @stefam, wäre schon der richtige Ansatz, denn ich will ja folgendes erreichen: Angenommen ich wäre der Entwickler des OXID-Paypal-Moduls und ich müsste ein neues DB-Feld ergänzen, weil es von Paypal ab 2021 neue Bestimmungen gibt, dann weiß ich zu dem Zeitpunkt nicht, in welchen OXID-Shops mein Modul installiert ist/ sein wird. Ich kann also die Migration nicht auf Projekt-Ebene durchführen, sondern brauche eine Lösung auf Modul-Ebene.
