How It Works: Magento 2 Partial Index

Anyone who has ever before used Magento 1 or Magento 2 is aware of such feature as index. It is pretty important and useful since exactly what is exhibited on the frontend relates to index. Indexing by itself is a pretty long process that's the reason partial index has been available almost since the first version of Magento. Incomplete index means that we index not the whole report but only the part that is modified.

View more : https://www.magebay.com

In Magento 2 EE there are available 2 indexing modes: Update on Save and Update by Schedule. You can configure each mode under Tools -> System -> Index Management. Each of them has its own benefits and drawbacks. The main benefit of the Update on Save method is the fact it lets you index data after saving the doc. In other words, once you save something in a category it becomes instantly on the frontend with all the changes that you have applied. However, the primary disadvantage is the fact it incredibly increases the time for each and every operation to complete. That is why, to speed up the process there has been introduced the Update by Schedule mode. This feature lets you index data in the background so there is absolutely no wait when you try to save any document. Everything is conducted asynchronously. The only real minus of this method is that it could really take a while before cron job starts off indexing.

In this specific article we will describe how incomplete index works. Let`s say that our default mode is Upgrade by Plan, so, if not indicated otherwise, the below information will concern exactly this method.

There is no special devote the Magento code where you can find partial index entities values. The whole reasoning of partial index is performed in a data source - via MySQL triggers if to become more specific. For example, the catalog_product_entity table contains 3 causes for the following situations: AFTER Add, AFTER Upgrade, AFTER DELETE

Let’s check the trigger for the AFTER INSERT event:

As seen from the above code the cause creates an archive in the *_cl tables in regards to a new entity. Let's check one of those *_cl tables. They are all identical, so, what's true for just one of these is also true for the others. Each table includes 2 fields: version_id and entity_id. The version_id field implies the existing changes version number, as the entity_id field shows the ids of the entities which need to be indexed.

When indexing is started by the cron job, the version_id values in the *_cl tables are compared to the data from the mview_point out table which contains the information about index variations and index position. On the code part the logic is managed by the Mview module which is a part of the Magento framework.

The cron job telephone calls the \Magento\Framework\Mview\View::update method that calls the required index. Let's have a look at this method a lttle bit closer:

For each index there is established a separate Mview class subject that is responsible for index update.

View more : https://productsdesignerpro.com/

Let's see the particular factors from the above code stand for:

• $currentVersionId - shows the existing version of the version_id field in the *_cl table;
• $lastVersionId - is the previous version of the matching index, extracted from the mview_state table;
• $ids - will be the ids of the entities that need to be indexed.

After that, each index becomes partially re-indexed in its way. Now let's see if it's possible to include custom causes to MySQL tables and perform custom incomplete indexing. Let's check the \Magento\Framework\Mview\View::subscribe method:

The first collection verifies whether partial indexing is empowered for the Mview index. Next, there is established a respected *_cl table. From then on the cycle undergoes the set of all users and creates causes in the MySQL desk. To include a custom view that will trail for changes in your Mview index tables you just need to build an mview.xml file in the component directory.

View more : product design tools

Let's describe one by one what each discussion is responsible for. For example, let's have a code test from the module Catalog-Permission:

This code creates the catalogpermissions_category_cl desk which is subscribed for changes in catalog_category_entity and catalog_category_entity_int tables' data. The data from entity_column - entity_id will be sent to the *_cl desk. This will lead to the causes of the next type:

For catalog_category_entity:

Re-indexing will be performed by the thing of the school field (see the $action varying in these code). But you might have noticed that we haven't used the registration_model field. This feature is recorded in the <table> field and it indicates the category which is accountable for creating sets off and their syntax. Certain triggers might not be as simple as explained above. In such instances one needs to use a custom model that is inherited from the default one. Here is an example of such a model from Magento 2 EE:

As you may see, your body of the result in differs from the result in which we created the first time.

From the above example you might observe how simple and tasteful a incomplete index is. You can redefine existing subscriptions without the problems (there have been such circumstances with the EE version when the designers simply forgot about the Staging module) as well as define your own subscriptions to utilize custom indexes.