It hasn’t been long when Magento first introduced Declarative Schema for the latest version 2.3. Said to have simplified the Magento installation and upgrade processes, the schema has been allowing developers to get away from writing updates for each new version in favour of declaring the final result they want to achieve.
Previously, in all Magento versions, developers were required to write a PHP script for installing and updating data in the database.
Various scripts were required for:
- Installing and updating the schema.
- Installing and updating data.
- Managing other operations when Magento was installed or upgraded.
Well, with the schema, developers are no longer forced to write scripts for each new version. In addition, this approach allows data to be deleted when a module is uninstalled.
Before losing your head over this innovation, let’s first have a closer look at it.
Declarative Schema: The Advantages
Because there is always room for improvement, Magento presented a declarative schema feature which seems to work like magic. It can simply be described as “no more lengthy scripts and data overload.”
When a customer upgrades Magento to a version several releases ahead of the installed version, the upgrade script for each intermediate release still executes. Developers are required to fully understand what each install and upgrade script contained. Further, they need to account for this complexity when creating extensions.
The new declarative schema approach eliminates this. It allows developers to declare the final desired state of the database and has the system adjust to it automatically, without performing redundant operations. Added to this, it helps with:
- Avoidmissed/repeated SQL operations
- dry-run mode for installation testing
- performance optimization: save time by moving from the current version to the final point
- support for rollbacks: developers can revert to a previous version
- validation before installation
- modification of existing columns
Having understood the concept, the next thing that might immediately come to your mind is
How to Configure Declarative Schema?
Consider the Module/etc/ folder create db_schema.xml. This is the file where we will define our tables, columns, and other needed stuff. Following is an example.
<table name=”table_name” resource=”default” engine=”innodb” comment=”Custom Table”>
<column xsi:type=”int” name=”id” padding=”10″ unsigned=”true” nullable=”false” identity=”true” comment=”ID”/>
<column xsi:type=”varchar” name=”title” comment=”Title”/>
<constraint xsi:type=”primary” referenceId=”PRIMARY”>
After adding the above code and running setup:upgrade, a table named as table_name will be automatically created with two columns – id and name – id being the primary key.
Now, 3 major parts that are used in the table node are:
- Column : Used to declare the column with its type in xsi:type
- Constraints : Used to define the constraints like unique, primary or foreign
- Index : Used for indexing purpose where you can define btree, fulltext or hash according to your requirements.
Using above, you can easily add/edit/delete columns, types, name and other things without creating a new version or new file. Just add or remove anything and it will be taken care of during the next setup upgrade.
Here, we will discuss briefly what data patches are and why to use them. In short, data patches are classes with data modification instructions.
Data Patch – A class that contains data modification instructions. It can have dependencies on other data or schema patches.
Revertable Data Patch – A data patch that contains a revert() method with provided operations that revert revertable changes caused by the module. Revertable operations are usually related to changes in the database.
Migration – A type of non-revertable data patch that can be applied, but not reverted. Any complex operation, one that contains an application layer is non-revertable. SQL delete operations are non-revertable because they can cause triggering.
Schema Patch – A class that contains custom schema modification instructions. Schema patches are used along with declarative schema, but these patches allow complex operations such as:
- Adding triggers, stored procedures, functions
- Performing data migration with inside DDL operations
- Renaming tables, columns, and other entities
- Adding partitions and options to a table
Revertable Schema Patch – A schema patch that contains a revert() method with the provided revert functionality. Like in the Revertable data patch, the revert functionality of the schema patch affects changes in the database only.
How to Configure Data Patches?
There are 3 methods in Data patches, getDependencies(), getAliases(), and apply(). As patches can depend on other patches, we should define the dependencies in the getDependencies() method:
Apply is the most important method in terms of this tutorial; its where we will put our code for the Patch.
This is an example of magento\module-catalog\Setup\Patch\Data\UpdateProductMetaDescription
As you can see, this is being used to add a note to the already existing attribute of Meta Description. You can adjust anything you like to add/remove/update in the apply method.
In conclusion, the declarative schema feature makes it easier for developers to work with the database. Furthermore, the process is faster and much simpler than it was before, which means performance will be improved.
For further information or implementation, get in touch with our Magento Certified Developers.