Database Structure and Schema Upgrade in Magento 2.0

Database Structure and Schema Upgrade in Magento 2.0

Modules database update process has some significant changes in comparison to the Magento 1. Now we can use 4 files to control database/data update process (located in the Setup folder):

  • InstallSchema.php  – tables and keys creation;
  • UpgradeSchema.php – updating tables’ schema;
  • InstallData.php – populating data into database (additional attributes, table data etc);
  • UpgradeData.php  – updating/adding new data;
  • Reccuring.php – initial launching of an application (for synchronization or indexing, but this feature enable only on Magento 2 EE version).

All the files are called in the order of the above listing. To install a module in Magento 2.0 you should run the following CLI command:

Let’s take a closer look to what exactly happens when the ‘setup/upgrade’ command is run.

Once called  the magento.php script creates and launches the console application —

This application uses incoming  arguments (in our case this is setup:upgrade) and calls the respective handler. The handler assignment and implementation is done in the Symfony\Component\Console\Application ::doRun() method

Here we determine the handler name based on the incoming command name ($name variable):

and then call the handler. In our case it is the object of the class Magento\Setup\Console\Command\UpgradeCommand.

The method Symfony\Component\Console\Application :: doRunCommand() launches the code of the handler (e.g. Magento\Setup\Console\Command\UpgradeCommand:execute()).

Here is the execte() method listing:

The factory method creates the Magento\Setup\Model\Installer $installer object. Installer runs  3 methods one by one:

  • updateModulesSequence()
  • installSchema()
  • installDataFixtures()

The method  Magento\Setup\Model\Installer::updateModulesSequence() verifies the deployment configuration, flushes cache, purges var/generate directory and passes modules’ configuration into the  Magento\Setup\Model\Installer::createModulesConfig() .

Let’s have a look at this step in more details.

The variable $all contains the list of all existing modules (this is defined by the properly configured <module-name>etc/module.xml files). The variable $deploymentConfig is filled with settings from configuration files config.php and env.php (see the directory <magento-install-dir>app/etc).

Database structure and schema upgrade in Magento 2.0

Here the value for $deploymentConfig[‘modules’] is taken from the file <magento-install-dir>app/etc/config.php . Further on the modules are verified for disable/enable in accordance with the file module.xml and the results are recorded into <magento-install-dir>app/etc/config.php.

The next step is to install table schema with the Magento\Setup\Model\Installer::installSchema() and Magento\Setup\Model\Installer ::handleDBSchemaData().

It is quite big, so we will touch only the most important moments.

It is clear that the update can be used only with 2 process types: schema and data.

Each of them can have 2 possible states that are recorded in the variables $installType and $upgradeType. The variable $moduleName contains the list of all modules. The variable $moduleContextList is filled with the modules’ version. The version data is taken from the setup_module table with the following structure:

Database structure and schema upgrade in Magento 2.0

As you see, the table contains the module name, current schema and data versions. The loop goes through all modules and compares the current version with the version in the module.xml file.  If record for the module is not found in the database the module’s  InstallShema.php or InstallData.php file is called.

If module update is required we have the following code:

In EE version we have also <Setup>/Reccuring.php file. This file is used for the initial application start, for example, when we need to synchronize data between a module and the Magento 2 core.

The same process is used to update data (for the files InstallData.php and UpgradeData.php).  The only difference is that the variable $type equals ‘data’ and, correspondingly, there will be called different objects, but the logic of the algorithm remains the same.

So, let’s make some conclusions:

Conclusion 1: To force the module reinstall we can remove record about the module from the table setup_module.

Conclusion 2: To reinstall data and implement only the file <magento-dir-install><module><Setup>/UpgradeData.php it is necessary to downgrade the data_version in the table  setup_module.

Conclusion 3: Magento no longer controls the versions of your application through different files (e.g. upgrade-0.2-0.3.php). Now, the version type is controlled by the developer through the files <magento-dir-install><module><Setup>/InstallShema.php and <magento-dir-install><module><Setup>/InstallData.php

Post a new comment