HOW IT OPERATES: Magento 2 Partial Index

12 Apr 2017 08:47
Tags

Back to list of posts

Anyone who has ever before used Magento 1 or Magento 2 knows about such feature as index. It really is quite important and useful since anything that is exhibited on the frontend is related to index. Indexing by itself is a pretty long process that's the reason incomplete index has been available almost since the first version of Magento. Incomplete index means that we index not the whole doc but only the part that is modified.

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

In Magento 2 EE there are available 2 indexing settings: Update on Save and Update by Schedule. You may configure each method under Tools -> System -> Index Management. Each of them has its own benefits and drawbacks. The main good thing about the Update on Save method is the fact it enables you to index data after saving the report. Quite simply, once you save something in a category it becomes instantly available on the frontend with all the changes that you have got applied. However, the key disadvantage is the fact it incredibly increases the time for every single procedure to complete. That is why, to increase the process there has been introduced the Update by Schedule function. This feature lets you index data in the backdrop so there is no hold off when you try to save any file. Everything is performed asynchronously. The one minus of the method is that it may really have a while before cron job starts indexing.

In this article we will describe how incomplete index works. Let`s say that our default mode is Upgrade by Program, so, if not mentioned often, the below information will concern exactly this technique.

There is no special place in the Magento code where you can find partial index entities principles. The whole reasoning of partial index is conducted in a data source - via MySQL causes if to be more specific. For instance, the catalog_product_entity table contains 3 triggers for the following occasions: AFTER Add, AFTER UPDATE, AFTER DELETE

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

As seen from the above code the lead to creates a record in the *_cl tables in regards to a new entity. Let's check one of those *_cl tables. All of them are identical, so, what is true for one of them is also true for others. Each table consists of 2 domains: version_id and entity_id. The version_id field indicates the existing changes version amount, as the entity_id field shows the ids of the entities which need to be indexed.

When indexing is started out by the cron job, the version_id beliefs in the *_cl desks are set alongside the data from the mview_condition table which contains the information about index types and index status. For the code aspect the reasoning is controlled by the Mview module which really is a part of the Magento framework.

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

For each index there is created another Mview class subject that is accountable for index update.

View more : https://productsdesignerpro.com/

Let's see what the parameters from the above code stand for:

$currentVersionId - implies the current version of the version_id field in the *_cl stand;
$lastVersionId - is the previous version of the corresponding index, extracted from the mview_point out table;
$ids - will be the ids of the entities that need to be indexed.
From then on, each index becomes partly re-indexed in its way. Now let's see if it's possible to add custom causes to MySQL furniture and perform custom partial indexing. Let's check the \Magento\Framework\Mview\View::subscribe method:

The first brand verifies whether incomplete indexing is allowed for the Mview index. Next, there is created a respective *_cl table. After that the cycle goes through the list of all users and creates sets off in the MySQL desk. To include a custom view that will keep track of for changes in your Mview index furniture you just need to set-up an mview.xml document in the module 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 component Catalog-Permission:

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

For catalog_category_entity:

Re-indexing will be performed by the object of the course field (see the $action changing in the above mentioned code). Nevertheless, you might have noticed that we haven't used the registration_model field. This attribute is noted in the <desk> field and this implies the course which is responsible for creating causes and their syntax. Certain causes is probably not as easy as identified above. In such instances one needs to use a custom model that is inherited from the default one. Here's a good example of such a model from Magento 2 EE:

As you see, the body of the lead to differs from the lead to which we created the very first time.

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

Comments: 0

Add a New Comment

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License