Halo semuanya. Publikasi ini tidak berpura-pura menjadi judul kebenaran pada contoh pertama, tetapi hanya pendapat pribadi saya, jika Anda membagikannya dengan sempurna, jika tidak, saya meminta komentar untuk diskusi.
Jadi, lebih dekat ke intinya. Dalam versi Magento 2.3 dan lebih tinggi, ada "roti" sebagai skema deklaratif. Apa skema deklaratif ini? Jika kita beralih ke dokumentasi Magento, maka itu ditulis dalam hitam dan putih - “Skema deklaratif ditujukan untuk menyederhanakan instalasi dan memperbarui Magento”.
Semuanya tampak hebat, karena sebelum para pengembang harus menulis banyak instal dan memutakhirkan skrip (di M1 ada sedikit mimpi buruk dengan mereka secara umum), hingga versi 2.3 itu perlu untuk menyimpan sejumlah skrip tertentu tergantung pada tugas, yaitu:
InstallSchema - kelas ini diluncurkan ketika modul diinstal untuk mengkonfigurasi struktur database.
InstallData - kelas ini diluncurkan ketika modul diinstal untuk menginisialisasi data tabel database.
UpgradeSchema - kelas ini diluncurkan ketika modul diperbarui untuk mengkonfigurasi struktur database.
UpgradeData - kelas ini diluncurkan ketika modul diperbarui untuk menambah / menghapus data dari tabel.
Copot pemasangan - kelas ini diluncurkan untuk menghapus data dan tabel dari database.
Setuju, ini lebih baik daripada menulis naskah terpisah untuk setiap bersin. Tapi ini ternyata tidak terlalu nyaman, karena saya harus mengikuti versi, melacak dan memahami apa yang Anda miliki dalam skrip ini, dan selain itu, mereka tumbuh menjadi "tapak kaki" besar dari 4000 + baris. Akibatnya, pendekatan ini ternyata gagal. Jumlah file telah menurun, tetapi jumlah baris kode telah meningkat.
Kemudian skema deklaratif datang untuk menyelamatkan. Bahkan, itu turun ke satu file -
db_schema.xml . Di mana Anda menyimpan keadaan akhir dari basis data. Artinya, jika Anda membutuhkan tabel khusus untuk modul, Anda menjelaskan bidang yang diperlukan dalam file ini dan hanya itu. Selanjutnya, magenta akan membuat tabel untuk Anda. Jika Anda perlu memperbarui tabel yang sudah dibuat sebelumnya, Anda hanya perlu mengubah file
db_schema.xml dan itu saja (keajaiban akan terjadi dengan sendirinya). Tidak perlu memantau pembuatan versi, tidak perlu menulis skrip pembaruan basis data untuk setiap versi modul yang baru, bahkan tidak perlu melakukan operasi yang tidak perlu. Setuju - itu keren.
Tapi tidak ada lalat di salep tanpa lalat di salep. (Ini bukan kesalahan ketik, yang bekerja dengan Magento akan mengerti saya :)).
Skema deklaratif hanya baik ketika bekerja dengan tabel kustom. Jika Anda perlu menambahkan atribut secara terprogram ke suatu produk atau kategori, buatlah INSERT atau UPDATE, atau akhirnya ubah sesuatu dalam Skema, silakan tulis tambalan. Kami akan membicarakannya di bawah.
Misalnya, pertimbangkan untuk menambahkan atribut khusus untuk suatu produk.
1. Mari kita mulai dengan membuat kelas berikut dalam modul:
Setup \ Patch \ Data \ AddAlternativeNameAttribute.phpYang untuk memulai akan berisi konten berikut
<?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 mengharapkan implementasi tiga fungsi:
berlaku ,
getDependencies , dan
getAliases .
2. Fungsi
terapkan adalah tempat di mana elemen atribut dibuat. Sekarang tidak perlu memanggil fungsi startSetup dan endSetup di sini, karena kita hanya membuat atribut. Untuk melakukan ini, buat instance EavSetupFactory, melewati objek moduleDataSetup kami, dan tambahkan atribut kami:
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. Fungsi
getDependencies mengharapkan array string yang berisi nama-nama kelas dependensi. Ini adalah fungsi baru yang muncul khusus untuk skrip skema deklaratif, dan memberitahu Magento bahwa perlu untuk menjalankan "tambalan" yang telah kami tetapkan di sini sebelum skrip instalasi kami. Beginilah cara Magento mengontrol urutan eksekusi skrip tambalan.
public static function getDependencies() { return []; }
4. Fungsi
getAliases terakhir yang mendefinisikan alias untuk tambalan ini. Karena kita tidak lagi menentukan nomor versi, nama kelas kita dapat berubah, dan jika ini terjadi, kita harus menentukan nama kelas yang lama di sini agar tidak berjalan untuk kedua kalinya (tambalan hanya dijalankan sekali)
public function getAliases() { return []; }
Kelas terakhir akan terlihat seperti ini:
<?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. Sekarang jalankan
pengaturan bin / magento: tingkatkan sehingga tambalan kami berlaku. Untuk semua tambalan yang telah berhasil dieksekusi, Magento menyisipkan entri ke dalam
tabel basis data
patch_list dengan nilai bidang
patch_name sama dengan nilai kelas kami (Foo \ Bar \ Setup \ Patch \ Data \ AddAlternativeNameAttribute).
6. Menghapus nilai dari tabel
patch_list akan menyebabkan tambalan berjalan kembali ketika pengaturan
bin / magento: pemutakhiran instalasi dimulai. Fungsi ini akan berguna saat men-debug tambalan.
Hasilnya:
+ Skema deklaratif menyederhanakan pekerjaan dengan tabel kustom
+ Kurangnya kebutuhan untuk memonitor versi
+ Peningkatan data yang mudah dalam tabel dan kustomisasi bidang tabel
- Ketidakmampuan untuk menambahkan atribut ke kategori produk melalui skema deklaratif
- Jika modul bersifat universal untuk versi 2.1, 2.2, 2.3, Anda harus menulis skema deklaratif dan skrip instalasi.
- Kebutuhan untuk menulis tambalan untuk bekerja dengan tabel inti.
Mungkin di masa mendatang, ketika M2 sepenuhnya beralih ke skema deklaratif dan tidak perlu menulis tambalan, itu akan sangat nyaman. Tetapi apakah ini akan terjadi dan ketika itu terjadi, pertanyaannya tetap terbuka.