مخطط التعريفي وما هو الخطأ في Magento 2

مرحبا بالجميع. لا يتظاهر هذا المنشور بأنه عنوان الحقيقة في المقام الأول ، بل هو رأيي الشخصي فقط ، إذا كنت تشاركه تمامًا ، إن لم يكن كذلك ، أطلبه في التعليقات للمناقشة.

لذلك ، أقرب إلى هذه النقطة. في الإصدار Magento 2.3 والإصدارات الأحدث ، كان هناك مثل هذا "الكعكة" كمخطط تعريفي. ما هو هذا المخطط التعريفي؟ إذا انتقلنا إلى وثائق Magento ، فسيتم كتابتها بالأبيض والأسود - "مخطط تعريفي يهدف إلى تبسيط عملية تثبيت Magento وتحديثه".

يبدو أن كل شيء رائع ، لأنه قبل أن يضطر المطورون إلى كتابة الكثير من برامج التثبيت والترقية (في M1 كان هناك كابوس صغير معهم بشكل عام) ، وحتى الإصدار 2.3 ، كان من الضروري الاحتفاظ بعدد معين من البرامج النصية وفقًا للمهام ، وهي:

InstallSchema - يتم تشغيل هذه الفئة عند تثبيت الوحدة النمطية لتكوين بنية قاعدة البيانات.
InstallData - يتم تشغيل هذه الفئة عند تثبيت الوحدة النمطية لتهيئة بيانات جدول قاعدة البيانات.
UpgradeSchema - يتم تشغيل هذه الفئة عند تحديث الوحدة النمطية لتكوين بنية قاعدة البيانات.
UpgradeData - يتم تشغيل هذه الفئة عند تحديث الوحدة لإضافة / إزالة البيانات من الجدول.
إلغاء التثبيت - يتم تشغيل هذه الفئة لإزالة البيانات والجداول من قاعدة البيانات.

توافق ، هذا أفضل من كتابة برنامج نصي منفصل لكل عطس. ولكن تبين أن هذا ليس مناسبًا جدًا ، حيث كان عليّ أن أتابع الإصدارات وتعقب وفهم ما لديك في هذه النصوص ، وعلاوة على ذلك ، نمت لتصبح "موطئ قدم" ضخمة تضم 4000 خط. نتيجة لذلك ، تحول هذا النهج إلى فشل كبير. انخفض عدد الملفات ، ولكن زاد عدد أسطر التعليمات البرمجية.

ثم جاء المخطط التعريفي للإنقاذ. في الواقع ، لقد وصل الأمر إلى ملف واحد - db_schema.xml . حيث يمكنك تخزين الحالة النهائية لقاعدة البيانات. هذا هو ، إذا كنت بحاجة إلى جدول مخصص للوحدة النمطية ، فإنك تصف الحقول اللازمة في هذا الملف وهذا كل شيء. بعد ذلك ، ستقوم أرجواني بإنشاء جدول لك. إذا كنت بحاجة إلى تحديث جدول تم إنشاؤه بالفعل في وقت سابق ، فأنت تقوم فقط بإجراء تغييرات على ملف db_schema.xml وكل هذا (سيحدث السحر بنفسه). لا تحتاج إلى مراقبة الإصدار ، ولا تحتاج إلى كتابة برامج نصية لتحديث قاعدة البيانات لكل إصدار جديد من الوحدة ، في الواقع لا تحتاج إلى القيام بعمليات غير ضرورية. موافق - إنه رائع.

ولكن لا يوجد ذبابة في المرهم بدون ذبابة في المرهم. (هذه ليست خطأ مطبعي ، الذي يعمل مع الماجنتو سوف يفهمني :)).

مخطط التعريفي جيد فقط عند العمل مع الجداول المخصصة. إذا كنت بحاجة إلى إضافة سمة برمجيًا إلى منتج أو فئة ، أو أدخل INSERT أو UPDATE ، أو أخيرًا قم بتغيير شيء ما في Schema ، يرجى كتابة تصحيحات. سنتحدث عنها أدناه.

على سبيل المثال ، ضع في اعتبارك إضافة سمة مخصصة لأحد المنتجات.

1. لنبدأ بإنشاء الفصل التالي في الوحدة:
إعداد \ تصحيح \ بيانات \ AddAlternativeNameAttribute.php

والتي لبداية سوف تحتوي على المحتوى التالي

<?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 { /** @var ModuleDataSetupInterface */ private $moduleDataSetup; /** @var EavSetupFactory */ private $eavSetupFactory; /** * @param ModuleDataSetupInterface $moduleDataSetup * @param EavSetupFactory $eavSetupFactory */ public function __construct( ModuleDataSetupInterface $moduleDataSetup, EavSetupFactory $eavSetupFactory ) { $this->moduleDataSetup = $moduleDataSetup; $this->eavSetupFactory = $eavSetupFactory; } } 

تتوقع DataPatchInterface تنفيذ ثلاث وظائف: تطبيق ، getDependencies و getAliases .

2. وظيفة التطبيق هي المكان الذي يتم فيه إنشاء عناصر السمات. الآن ليست هناك حاجة لاستدعاء وظائف startSetup و endSetup هنا ، لأننا نقوم فقط بإنشاء سمات. للقيام بذلك ، قم بإنشاء مثيل EavSetupFactory ، ويمر كائن الوحدة النمطية DataSetup ، وقم بإضافة السمة الخاصة بنا:

  /** * {@inheritdoc} */ public function apply() { /** @var EavSetup $eavSetup */ $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. تتوقع الدالة getDependencies مجموعة من السلاسل التي تحتوي على أسماء فئات التبعية. هذه وظيفة جديدة ظهرت خصيصًا للنصوص البرمجية للمخطط التعريفي ، وهي تخبر Magento أنه من الضروري تنفيذ "التصحيحات" التي حددناها هنا قبل نص التثبيت الخاص بنا. هذه هي الطريقة التي يتحكم Magento ترتيب تنفيذ البرامج النصية التصحيح.

  /** * {@inheritdoc} */ public static function getDependencies() { return []; } 

4. وظيفة getAliases الأخيرة التي تحدد الأسماء المستعارة لهذا التصحيح. نظرًا لأننا لم نعد نحدد أرقام الإصدارات ، فقد يتغير اسم صفنا ، وإذا حدث ذلك ، يجب علينا تحديد اسم الفصل القديم هنا حتى لا يعمل مرة ثانية (يتم تشغيل التصحيحات مرة واحدة فقط)

  /** * {@inheritdoc} */ public function getAliases() { return []; } 

سيبدو الفصل النهائي كالتالي:

 <?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 { /** @var ModuleDataSetupInterface */ private $moduleDataSetup; /** @var EavSetupFactory */ private $eavSetupFactory; /** * @param ModuleDataSetupInterface $moduleDataSetup * @param EavSetupFactory $eavSetupFactory */ public function __construct( ModuleDataSetupInterface $moduleDataSetup, EavSetupFactory $eavSetupFactory ) { $this->moduleDataSetup = $moduleDataSetup; $this->eavSetupFactory = $eavSetupFactory; } /** * {@inheritdoc} */ public function apply() { /** @var EavSetup $eavSetup */ $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, ]); } /** * {@inheritdoc} */ public static function getDependencies() { return []; } /** * {@inheritdoc} */ public function getAliases() { return []; } } 

5. الآن قم بتشغيل إعداد bin / magento: قم بالترقية بحيث يتم تطبيق التصحيح الخاص بنا. بالنسبة لجميع التصحيحات التي تم تنفيذها بنجاح ، تقوم Magento بإدخال إدخال في جدول قاعدة بيانات patch_list بقيمة حقل patch_name تساوي قيمة فئتنا (Foo \ Bar \ Setup \ Patch \ Data \ AddAlternativeNameAttribute).

6. ستؤدي إزالة القيمة من جدول patch_list إلى إعادة تشغيل التصحيح عند إعداد bin / magento: يبدأ تثبيت الترقية . ستكون هذه الوظيفة مفيدة عند تصحيح الأخطاء.

النتيجة:

+ مخطط التعريفي يبسط العمل مع الجداول المخصصة
+ عدم وجود حاجة لمراقبة تعيين الإصدار
+ ترقية البيانات سهلة في الجداول وتخصيص حقول الجدول

- عدم القدرة على إضافة سمات إلى فئة المنتج من خلال مخطط تعريفي
- إذا كانت الوحدة النمطية عالمية للإصدارات 2.1 و 2.2 و 2.3 ، فسوف يتعين عليك كتابة كل من المخطط التعريفي ونصوص التثبيت.
- الحاجة إلى كتابة بقع للعمل مع الجداول الأساسية.

ربما في المستقبل المنظور ، عندما تنتقل M2 بالكامل إلى مخطط إعلاني ولا توجد حاجة لكتابة تصحيحات ، ستكون مريحة للغاية. ولكن ما إذا كان هذا سيحدث ومتى يحدث ، يبقى السؤال مفتوحًا.