👩🏽‍🤝‍👩🏻 😞 🧜 घोषणा योजना और इसके साथ गलत क्या है Magento 2 🕺🏿 👨🏿‍🏭 🏳️‍🌈

सभी को नमस्कार। यह प्रकाशन पहली बार में सत्य का शीर्षक होने का दिखावा नहीं करता है, लेकिन केवल मेरी व्यक्तिगत राय है, अगर आप इसे पूरी तरह से साझा करते हैं, यदि नहीं, तो मैं चर्चा के लिए टिप्पणियों में पूछता हूं।

तो, बिंदु के करीब। संस्करण Magento 2.3 और उच्चतर में, एक घोषणात्मक योजना के रूप में इस तरह के "गोखरू" था। यह घोषित योजना क्या है? अगर हम Magento के प्रलेखन की ओर मुड़ते हैं, तो यह काले और सफेद रंग में लिखा जाता है - "एक घोषणा योजना का उद्देश्य Magento की स्थापना और अद्यतन को सरल बनाना है"।

सब कुछ बहुत अच्छा लगता है, क्योंकि इससे पहले कि डेवलपर्स को बहुत सारी स्थापित और अपग्रेड स्क्रिप्ट लिखना पड़ता था (एम 1 में सामान्य रूप से उनके साथ थोड़ा बुरा सपना था), संस्करण 2.3 तक यह आवश्यक था कि कार्यों के आधार पर एक निश्चित संख्या में स्क्रिप्ट रखी जाए, अर्थात्

InstallSchema - डेटाबेस संरचना को कॉन्फ़िगर करने के लिए मॉड्यूल स्थापित होने पर यह वर्ग लॉन्च किया जाता है।
InstallData - यह वर्ग लॉन्च किया जाता है जब डेटाबेस डेटाबेस टेबल डेटा को इनिशियलाइज़ करने के लिए इंस्टॉल किया जाता है।
UpgradSchema - डेटाबेस संरचना को कॉन्फ़िगर करने के लिए मॉड्यूल अपडेट किए जाने पर यह वर्ग लॉन्च किया जाता है।
UpgradData - यह वर्ग लॉन्च किया जाता है जब मॉड्यूल को तालिका से डेटा जोड़ने / हटाने के लिए अद्यतन किया जाता है।
अनइंस्टॉल - यह वर्ग डेटाबेस से डेटा और तालिकाओं को हटाने के लिए लॉन्च किया गया है।

सहमत हूं, यह प्रत्येक छींक के लिए एक अलग स्क्रिप्ट लिखने से बेहतर है। लेकिन यह बहुत सुविधाजनक नहीं था, क्योंकि मुझे इन लिपियों में संस्करण, ट्रैक और समझने का पालन करना था और इसके अलावा, वे 4000+ लाइनों के विशाल "फुटक्लॉथ" में विकसित हुए। नतीजतन, यह दृष्टिकोण काफी असफल रहा। फाइलों की संख्या में कमी आई है, लेकिन कोड की लाइनों की संख्या में वृद्धि हुई है।

तब घोषणा योजना बचाव में आई। वास्तव में, यह एक एकल फ़ाइल में आया - db_schema.xml । जिसमें आप डेटाबेस की अंतिम स्थिति को स्टोर करते हैं। यही है, यदि आपको मॉड्यूल के लिए एक कस्टम टेबल की आवश्यकता है, तो आप इस फ़ाइल में आवश्यक फ़ील्ड और उसका वर्णन करते हैं। इसके बाद, मैजंटा आपके लिए एक टेबल बनाएगा। यदि आपको पहले से बनाई गई तालिका को अपडेट करने की आवश्यकता है, तो आप बस db_schema.xml फ़ाइल में परिवर्तन करते हैं और यह सब (जादू अपने आप होगा)। आपको संस्करण की निगरानी करने की आवश्यकता नहीं है, आपको मॉड्यूल के प्रत्येक नए संस्करण के लिए डेटाबेस को अपडेट करने के लिए स्क्रिप्ट लिखने की आवश्यकता नहीं है, वास्तव में आपको अनावश्यक संचालन करने की आवश्यकता नहीं है। सहमत - यह अच्छा है।

लेकिन मरहम में एक मक्खी के बिना मरहम में कोई मक्खी नहीं है। (यह एक टाइपो नहीं है, जो मैगेंटो के साथ काम करता है मुझे समझ जाएगा :))।

कस्टम टेबल के साथ काम करने के दौरान ही घोषणात्मक योजना अच्छी है। यदि आपको किसी उत्पाद या श्रेणी में प्रोग्रामेटिक रूप से कोई विशेषता जोड़ने की आवश्यकता है, तो INSERT या UPDATE करें, या अंत में स्कीमा में कुछ बदलें, कृपया पैच लिखें। हम उनके बारे में नीचे बात करेंगे।

उदाहरण के लिए, किसी उत्पाद के लिए एक कस्टम विशेषता जोड़ने पर विचार करें।

1. आइए मॉड्यूल में निम्न वर्ग बनाकर शुरू करें:
सेटअप \ Patch \ Data \ 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 तीन कार्यों के कार्यान्वयन की अपेक्षा करता है: लागू करें , getD dependencies और getAliases ।

2. लागू फ़ंक्शन वह स्थान है जहां विशेषता तत्व बनाए जाते हैं। अब यहां स्टार्टअप शुरू करने और एंडसेटअप फ़ंक्शन को कॉल करने की आवश्यकता नहीं है, क्योंकि हम केवल विशेषताएँ बनाते हैं। ऐसा करने के लिए, 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, ]); }

3. गेटडिपेंडेंसी फ़ंक्शन स्ट्रिंग्स की एक सरणी की अपेक्षा करता है जिसमें निर्भरता वर्गों के नाम शामिल हैं। यह नई कार्यक्षमता है जो विशेष रूप से घोषणात्मक स्कीमा स्क्रिप्ट के लिए दिखाई देती है, और यह मैगेंटो को बताती है कि इसे "पैच" को निष्पादित करने की आवश्यकता है जिसे हमने अपनी स्थापना स्क्रिप्ट से पहले यहां परिभाषित किया था। यह मैगेंटो पैच स्क्रिप्ट के निष्पादन क्रम को नियंत्रित करता है।

  /** * {@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. अब बिन / मैग्नेटो सेटअप चलाएं : अपग्रेड करें ताकि हमारा पैच लागू हो। सभी पैच जिन्हें सफलतापूर्वक निष्पादित किया गया है, मैगेंटो हमारे वर्ग (Foo \ Bar \ Setup \ Patch \ Patch \ Data \ AddAlternativeNnAttribute) के मान के बराबर पैच_name फ़ील्ड मान के साथ पैच_लिस्ट डेटाबेस तालिका में एक प्रविष्टि सम्मिलित करता है।

6. पैच / सूची तालिका से मान को हटाने से पैच बिन / मैगेंटो सेटअप: नवीनीकरण स्थापना शुरू होने पर फिर से चलाने का कारण होगा। पैच को डीबग करते समय यह कार्यक्षमता उपयोगी होगी।

परिणाम:

+ घोषणा योजना कस्टम तालिकाओं के साथ काम को सरल बनाती है
+ संस्करण की निगरानी की आवश्यकता की कमी
+ तालिकाओं में आसान डेटा उन्नयन और टेबल फ़ील्ड के अनुकूलन

- एक घोषणा योजना के माध्यम से उत्पाद श्रेणी में विशेषताओं को जोड़ने में असमर्थता
- यदि मॉड्यूल 2.1, 2.2, 2.3 संस्करणों के लिए सार्वभौमिक है, तो आपको एक घोषणा योजना और स्थापना स्क्रिप्ट दोनों लिखना होगा।
- कोर टेबल के साथ काम करने के लिए पैच लिखने की आवश्यकता।

शायद भविष्य में, जब एम 2 पूरी तरह से एक घोषणात्मक योजना में बदल जाता है और पैच लिखने की आवश्यकता नहीं होती है, तो यह सुपर सुविधाजनक होगा। लेकिन क्या ऐसा होगा और कब होता है, यह सवाल खुला है।

घोषणा योजना और इसके साथ गलत क्या है Magento 2

More articles: