Hallo an alle. Diese Veröffentlichung gibt in erster Linie nicht vor, der Titel der Wahrheit zu sein, sondern ist nur meine persönliche Meinung, wenn Sie sie perfekt teilen, wenn nicht, bitte ich in den Kommentaren um Diskussion.
Also näher am Punkt. In Version Magento 2.3 und höher gab es ein solches „Brötchen“ als deklaratives Schema. Was ist dieses deklarative Schema? Wenn wir uns der Magento-Dokumentation zuwenden, wird sie in Schwarzweiß geschrieben: „Ein deklaratives Schema soll die Installation und Aktualisierung von Magento vereinfachen.“
Alles scheint großartig zu sein, denn bevor die Entwickler viele Installations- und Upgrade-Skripte schreiben mussten (in M1 gab es im Allgemeinen einen kleinen Albtraum), war es bis Version 2.3 erforderlich, eine bestimmte Anzahl von Skripten abhängig von den Aufgaben beizubehalten, nämlich:
InstallSchema - Diese Klasse wird gestartet, wenn das Modul zum Konfigurieren der Datenbankstruktur installiert wird.
InstallData - Diese Klasse wird gestartet, wenn das Modul zum Initialisieren von Datenbanktabellendaten installiert wird.
UpgradeSchema - Diese Klasse wird gestartet, wenn das Modul aktualisiert wird, um die Datenbankstruktur zu konfigurieren.
UpgradeData - Diese Klasse wird gestartet, wenn das Modul aktualisiert wird, um Daten zur Tabelle hinzuzufügen / daraus zu entfernen.
Deinstallieren - Diese Klasse wird gestartet, um Daten und Tabellen aus der Datenbank zu entfernen.
Stimmen Sie zu, dies ist besser, als für jedes Niesen ein separates Skript zu schreiben. Dies stellte sich jedoch als nicht sehr praktisch heraus, da ich der Versionierung folgen, verfolgen und verstehen musste, was Sie in diesen Skripten haben, und außerdem wuchsen sie zu riesigen "Fußtüchern" mit mehr als 4000 Zeilen. Infolgedessen erwies sich dieser Ansatz als ziemlich fehlgeschlagen. Die Anzahl der Dateien hat abgenommen, aber die Anzahl der Codezeilen hat zugenommen.
Dann kam das deklarative Schema zur Rettung. Tatsächlich
kam es auf eine einzelne Datei an -
db_schema.xml . In dem Sie den Endzustand der Datenbank speichern. Wenn Sie also eine benutzerdefinierte Tabelle für das Modul benötigen, beschreiben Sie die erforderlichen Felder in dieser Datei und fertig. Als nächstes erstellt das Magenta eine Tabelle für Sie. Falls Sie eine bereits zuvor erstellte Tabelle aktualisieren müssen, nehmen Sie einfach Änderungen an der Datei
db_schema.xml vor und das ist alles (die Magie geschieht von selbst). Sie müssen die Versionsverwaltung nicht überwachen, Sie müssen keine Skripts zum Aktualisieren der Datenbank für jede neue Version des Moduls schreiben, und Sie müssen keine unnötigen Vorgänge ausführen. Stimme zu - es ist cool.
Aber es gibt keine Fliege in der Salbe ohne eine Fliege in der Salbe. (Dies ist kein Tippfehler, wer mit Magento arbeitet, wird mich verstehen :)).
Das deklarative Schema ist nur dann gut, wenn Sie mit benutzerdefinierten Tabellen arbeiten. Wenn Sie einem Produkt oder einer Kategorie programmgesteuert ein Attribut hinzufügen, ein INSERT oder UPDATE erstellen oder schließlich etwas im Schema ändern müssen, schreiben Sie bitte Patches. Wir werden unten darüber sprechen.
Ziehen Sie beispielsweise in Betracht, ein benutzerdefiniertes Attribut für ein Produkt hinzuzufügen.
1. Beginnen wir mit der Erstellung der folgenden Klasse im Modul:
Setup \ Patch \ Data \ AddAlternativeNameAttribute.phpWelche für den Anfang wird den folgenden Inhalt enthalten
<?php namespace Foo\Bar\Setup\Patch\Data; use Magento\Eav\Setup\EavSetupFactory; use Magento\Framework\Setup\ModuleDataSetupInterface; use Magento\Framework\Setup\Patch\DataPatchInterface; class AddAlternativeNameAttribute implements DataPatchInterface { private $moduleDataSetup; private $eavSetupFactory; public function __construct( ModuleDataSetupInterface $moduleDataSetup, EavSetupFactory $eavSetupFactory ) { $this->moduleDataSetup = $moduleDataSetup; $this->eavSetupFactory = $eavSetupFactory; } }
Das DataPatchInterface erwartet die Implementierung von drei Funktionen:
apply ,
getDependencies und
getAliases .
2. Die
Apply- Funktion ist der Ort, an dem Attributelemente erstellt werden. Jetzt müssen die Funktionen startSetup und endSetup hier nicht mehr aufgerufen werden, da nur Attribute erstellt werden. Erstellen Sie dazu eine Instanz von EavSetupFactory, übergeben Sie unser moduleDataSetup-Objekt und fügen Sie unser Attribut hinzu:
public function apply() { $eavSetup = $this->eavSetupFactory->create(['setup' => $this->moduleDataSetup]); $eavSetup->addAttribute('catalog_product', 'alternative_name', [ 'type' => 'varchar', 'label' => 'Alternative Name', 'input' => 'text', 'used_in_product_listing' => true, 'user_defined' => true, ]); }
3. Die Funktion
getDependencies erwartet ein Array von Zeichenfolgen, das die Namen der Abhängigkeitsklassen enthält. Dies ist eine neue Funktionalität, die speziell für deklarative Schemaskripte angezeigt wurde und Magento mitteilt, dass die hier definierten „Patches“ vor unserem Installationsskript ausgeführt werden müssen. Auf diese Weise steuert Magento die Ausführungsreihenfolge von Patch-Skripten.
public static function getDependencies() { return []; }
4. Die letzte Funktion
getAliases , die die Aliase für diesen Patch definiert. Da wir keine Versionsnummern mehr angeben, kann sich der Name unserer Klasse ändern. In diesem Fall müssen wir hier den alten Klassennamen angeben, damit er nicht ein zweites Mal ausgeführt wird (Patches werden nur einmal ausgeführt).
public function getAliases() { return []; }
Die letzte Klasse wird so aussehen:
<?php namespace Foo\Bar\Setup\Patch\Data; use Magento\Eav\Setup\EavSetup; use Magento\Eav\Setup\EavSetupFactory; use Magento\Framework\Setup\ModuleDataSetupInterface; use Magento\Framework\Setup\Patch\DataPatchInterface; class AddAlternativeNameAttribute implements DataPatchInterface { private $moduleDataSetup; private $eavSetupFactory; public function __construct( ModuleDataSetupInterface $moduleDataSetup, EavSetupFactory $eavSetupFactory ) { $this->moduleDataSetup = $moduleDataSetup; $this->eavSetupFactory = $eavSetupFactory; } public function apply() { $eavSetup = $this->eavSetupFactory->create(['setup' => $this->moduleDataSetup]); $eavSetup->addAttribute('catalog_product', 'alternative_name', [ 'type' => 'varchar', 'label' => 'Alternative Name', 'input' => 'text', 'used_in_product_listing' => true, 'user_defined' => true, ]); } public static function getDependencies() { return []; } public function getAliases() { return []; } }
5. Führen Sie nun das
bin / magento-Setup aus: Aktualisieren Sie, damit unser Patch
angewendet wird . Für alle Patches, die erfolgreich ausgeführt wurden, fügt Magento einen Eintrag in die
Patch-List- Datenbanktabelle ein, dessen
Feldwert patch_name dem Wert unserer Klasse entspricht (Foo \ Bar \ Setup \ Patch \ Data \ AddAlternativeNameAttribute).
6.
Wenn Sie den Wert aus der Tabelle
patch_list entfernen , wird der Patch erneut ausgeführt, wenn die Installation von
bin / magento setup: upgrade gestartet wird . Diese Funktionalität ist beim Debuggen von Patches hilfreich.
Das Ergebnis:
+ Das deklarative Schema vereinfacht die Arbeit mit benutzerdefinierten Tabellen
+ Keine Notwendigkeit, die Versionierung zu überwachen
+ Einfache Datenaktualisierung in Tabellen und Anpassung von Tabellenfeldern
- Die Unfähigkeit, der Produktkategorie über ein deklaratives Schema Attribute hinzuzufügen
- Wenn das Modul für die Versionen 2.1, 2.2, 2.3 universell ist, müssen Sie sowohl ein deklaratives Schema als auch Installationsskripte schreiben.
- Die Notwendigkeit, Patches für die Arbeit mit Kerntabellen zu schreiben.
Vielleicht ist es in absehbarer Zeit sehr praktisch, wenn M2 vollständig auf ein deklaratives Schema umstellt und keine Patches geschrieben werden müssen. Aber ob dies passieren wird und wann, wird die Frage offen bleiben.