Declarative Schema Data Patch in Magento 2.3

In the previous blog, I introduced the declarative schema in Magento 2.3. In this blog, I am going to elaborate on the Data Patch. It is a new concept in the Declarative Schema approach. A data patch is a class that contains the data modification instruction.

The patch is defined in Vendor\Module\Setup\Patch\Data\Patch_Name.php file and implements \Magento\Framework\Setup\Patch\DataPatchInterface.

The declarative schema approach removes the version from the setup_module table, leaving only the Composer version. Therefore, you can create all-new patches and modules without specifying a setup_module version.

Create EAV Attribute using Declarative Schema in Magento 2.3

I was stuck in the moments of creating product attributes using declarative schema. So I came to know that, however declarative schema script doesn’t apply to creating product attributes. For that, we need to implement patches that will create attributes.

We need to create a class that implements DataPatchInterface and instantiates the EavSetupFactory class within the constructor.

The naming convention for the patch file is, that if we are trying to add a single attribute named custom_size, we name our class AddCustomSizeAttribute.

Following are the steps to create eav attribute using the data patch in the declarative schema.

Create Setup\Patch\Data within your module. Create file AddCustomSizeAttribute.php inside the Data folder. Write down the following code in the file.

<?php

namespace StageBit\DeclarativeSchema\Setup\Patch\Data;

use Magento\Eav\Setup\EavSetupFactory;
use Magento\Framework\Setup\Patch\DataPatchInterface;

class AddCustomSizeAttribute implements DataPatchInterface
{
    /**
     * @var EavSetupFactory
     */
    protected $_eavSetupFactory;

    /**
     * @var \Magento\Framework\Setup\ModuleDataSetupInterface
     */
    protected $_moduleDataSetup;

    /**
     * AddCustomSizeAttribute constructor.
     *
     * @param \Magento\Framework\Setup\ModuleDataSetupInterface $moduleDataSetup
     * @param EavSetupFactory $eavSetupFactory
     */
    public function __construct(
        \Magento\Framework\Setup\ModuleDataSetupInterface $moduleDataSetup,
        EavSetupFactory $eavSetupFactory
    ) {
        $this->_eavSetupFactory = $eavSetupFactory;
        $this->_moduleDataSetup = $moduleDataSetup;
    }
}

The DataPatchInterface needs to implement the functions: apply, getDependencies and getAliases.

The apply function is where we will create our attributes. We just create an instance of the EavSetupFactory, passing in our moduleDataSetup object, and add our attribute

public function apply()
{
    /** @var EavSetup $eavSetup */
    $eavSetup = $this->_eavSetupFactory->create(['setup' => $this->_moduleDataSetup]);
    $eavSetup->addAttribute('catalog_product', 'custom_size', [
        'type' => 'varchar',
        'label' => 'Custom Size',
        'input' => 'select',
        'source' => 'StageBit\DeclarativeSchema\Model\Custom\Source\CustomSize',
        'required' => false,
        'sort_order' => 50,
        'global' => \Magento\Eav\Model\Entity\Attribute\ScopedAttributeInterface::SCOPE_STORE,
        'is_used_in_grid' => true,
        'is_visible_in_grid' => false,
        'is_filterable_in_grid' => false,
        'visible' => true,
        'is_html_allowed_on_front' => true,
        'visible_on_front' => false
    ]);
}    

The getDependencies function expects an array of strings containing class names of dependencies. This tells Magento to execute the patches we define here first, before our setup script.

This is how Magento controls the order of how patch scripts are executed. In this situation, we won’t have any dependencies, so we’ll just return an empty array.

public static function getDependencies()
{
    return [];
}

The getAliases return the path names array. Some patches with time can change their names. Changing the name should not affect the installation process, that’s why if we will change the name of the patch we will add an alias here

public function getAliases()
{
    return [];
}

The getVersion function returns the version number. If the version number of the module is higher than the version we specify where in the code, the patch will not execute. If it is equal to or lower than the version here, it will execute.

public static function getVersion()
{
    return '1.0.1';
}

Now when we run php bin/magento setup:upgrade to apply the updates, our data patch executes and the attribute is created. For all patches which are successfully executed, Magento inserts a record into the patch_list database table with the value of the patch_name field being the value of our patch class.

Removing the value from the patch_list table will cause the patch to re-execute when running php bin/magento setup:upgrade again, so this approach can be extremely useful when first creating and debugging patch scripts. If you find this blog useful then comment and share this blog.