Bonjour à tous. Cette publication ne prétend pas être le titre de vérité en premier lieu, mais seulement mon opinion personnelle, si vous la partagez parfaitement, sinon, je demande dans les commentaires pour discussion.
Donc, plus près du point. Dans la version Magento 2.3 et supérieure, il y avait un tel «chignon» comme un schéma déclaratif. Quel est ce schéma déclaratif? Si nous nous tournons vers la documentation de Magento, elle est écrite en noir et blanc - «Un schéma déclaratif vise à simplifier l'installation et la mise à jour de Magento».
Tout semble bien se passer, car avant que les développeurs n'aient à écrire beaucoup de scripts d'installation et de mise à niveau (en M1 il y avait un petit cauchemar avec eux en général), jusqu'à la version 2.3 il fallait garder un certain nombre de scripts en fonction des tâches, à savoir:
InstallSchema - cette classe est lancée lorsque le module est installé pour configurer la structure de la base de données.
InstallData - cette classe est lancée lorsque le module est installé pour initialiser les données de table de base de données.
UpgradeSchema - cette classe est lancée lorsque le module est mis à jour pour configurer la structure de la base de données.
UpgradeData - cette classe est lancée lorsque le module est mis à jour pour ajouter / supprimer des données de la table.
Désinstaller - cette classe est lancée pour supprimer les données et les tables de la base de données.
D'accord, c'est mieux que d'écrire un script séparé pour chaque éternuement. Mais cela ne s'est pas avéré très pratique, car j'ai dû suivre le versionnage, suivre et comprendre ce que vous avez dans ces scripts, et en plus, ils sont devenus d'énormes "footcloths" de plus de 4000 lignes. En conséquence, cette approche s'est avérée être un échec. Le nombre de fichiers a diminué, mais le nombre de lignes de code a augmenté.
Puis le schéma déclaratif est venu à la rescousse. En fait, cela
se résumait à un seul fichier -
db_schema.xml . Dans lequel vous stockez l'état final de la base de données. Autrement dit, si vous avez besoin d'une table personnalisée pour le module, vous décrivez les champs nécessaires dans ce fichier et c'est tout. Ensuite, le magenta créera une table pour vous. Si vous devez mettre à jour une table déjà créée plus tôt, vous n'avez qu'à apporter des modifications au fichier
db_schema.xml et c'est tout (la magie se produira d'elle-même). Vous n'avez pas besoin de surveiller la gestion des versions, vous n'avez pas besoin d'écrire des scripts pour mettre à jour la base de données pour chaque nouvelle version du module, en fait, vous n'avez pas besoin d'effectuer des opérations inutiles. D'accord - c'est cool.
Mais il n'y a pas de mouche dans la pommade sans mouche dans la pommade. (Ce n'est pas une faute de frappe, qui travaille avec magento me comprendra :)).
Le schéma déclaratif n'est valable que lorsque vous travaillez avec des tables personnalisées. Si vous devez ajouter un attribut par programme à un produit ou une catégorie, créer un INSERT ou une MISE À JOUR, ou enfin changer quelque chose dans le schéma, veuillez écrire des correctifs. Nous en parlerons ci-dessous.
Par exemple, envisagez d'ajouter un attribut personnalisé pour un produit.
1. Commençons par créer la classe suivante dans le module:
Setup \ Patch \ Data \ AddAlternativeNameAttribute.phpQui pour commencer contiendra le contenu suivant
<?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; } }
DataPatchInterface attend l'implémentation de trois fonctions:
apply ,
getDependencies et
getAliases .
2. La fonction d'
application est l'endroit où les éléments d'attribut sont créés. Maintenant, il n'est pas nécessaire d'appeler les fonctions startSetup et endSetup ici, car nous ne créons que des attributs. Pour ce faire, créez une instance de EavSetupFactory, en passant notre objet moduleDataSetup, et ajoutez notre attribut:
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. La fonction
getDependencies attend un tableau de chaînes qui contient les noms des classes de dépendance. Il s'agit d'une nouvelle fonctionnalité qui est apparue spécifiquement pour les scripts de schéma déclaratif, et elle indique à Magento qu'il est nécessaire d'exécuter les «correctifs» que nous avons définis ici avant notre script d'installation. C'est ainsi que Magento contrôle l'ordre d'exécution des scripts de patch.
public static function getDependencies() { return []; }
4. La dernière fonction
getAliases qui définit les alias de ce correctif. Puisque nous ne spécifions plus les numéros de version, le nom de notre classe peut changer, et si cela se produit, nous devons spécifier ici l'ancien nom de la classe afin qu'il ne s'exécute pas une deuxième fois (les correctifs ne sont exécutés qu'une seule fois)
public function getAliases() { return []; }
La classe finale ressemblera à ceci:
<?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. Maintenant, exécutez la
configuration bin / magento: mettez à
niveau pour que notre patch s'applique. Pour tous les correctifs qui ont été exécutés avec succès, Magento insère une entrée dans la
table de base de données
patch_list avec la valeur du champ
patch_name égale à la valeur de notre classe (Foo \ Bar \ Setup \ Patch \ Data \ AddAlternativeNameAttribute).
6. La suppression de la valeur de la table
patch_list entraînera la
réexécution du correctif lors de l'
installation de bin / magento: l' installation de la
mise à niveau démarre. Cette fonctionnalité sera utile lors du débogage des correctifs.
Le résultat:
+ Le schéma déclaratif simplifie le travail avec des tableaux personnalisés
+ Manque de besoin de surveiller le contrôle de version
+ Mise à niveau facile des données dans les tableaux et personnalisation des champs de tableau
- L'incapacité d'ajouter des attributs à la catégorie de produits via un schéma déclaratif
- Si le module est universel pour les versions 2.1, 2.2, 2.3, vous devrez écrire à la fois un schéma déclaratif et des scripts d'installation.
- La nécessité d'écrire des correctifs pour travailler avec les tables de base.
Peut-être que dans un avenir prévisible, lorsque M2 passera complètement à un schéma déclaratif et qu'il n'y aura pas besoin d'écrire de correctifs, ce sera super pratique. Mais si cela se produira et quand cela arrivera, la question reste ouverte.