HOW IT OPERATES: Magento 2 Partial Indexin Clan Section Wed Apr 12, 2017 10:01 am
by magebaytn • 6 Posts
Whoever has ever used Magento 1 or Magento 2 knows about such feature as index. It is rather important and useful since exactly what is shown on the frontend relates to index. Indexing alone is a fairly long process that is why incomplete index has been available almost because the first version of Magento. Incomplete index means that people index not the complete file 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 could configure each setting under Tools -> System -> Index Management. All of them has its own benefits and drawbacks. The main good thing about the Update on Save setting is the fact that it lets you index data upon saving the record. In other words, once you save a product in a category it becomes instantly available on the frontend with all the changes which you have applied. However, the primary disadvantage is that it incredibly escalates the time for every single procedure to complete. That is why, to speed up the process there's been introduced the Update by Schedule function. This feature enables you to index data in the backdrop so there is absolutely no delay when you make an effort to save any record. Everything is conducted asynchronously. The only real minus of this method is that it may really have a while before cron job begins indexing.
In this article we are going to describe how partial index works. Let's assume our default mode is Update by Timetable, so, if not indicated otherwise, the below description will concern exactly this technique.
There is absolutely no special devote the Magento code where you can find incomplete index entities prices. The whole logic of partial index is conducted in a repository - via MySQL triggers if to be more specific. For example, the catalog_product_entity desk contains 3 sets off for the following occasions: AFTER Place, AFTER Upgrade, AFTER DELETE
Let’s check the trigger for the AFTER INSERT event:
As seen from the above code the trigger creates an archive in the *_cl desks about 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 is made up of 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 out by the cron job, the version_id prices in the *_cl furniture are compared to the information from the mview_state table which contains the information about index variants and index position. For the code part the reasoning is controlled by the Mview module which is a area of the Magento framework.
The cron job message or calls the \Magento\Framework\Mview\View::update method that telephone calls the mandatory index. Let's check out this method a bit closer:
For every index there is established a separate Mview class thing that is in charge of index update.
View more : https://productsdesignerpro.com/
Let's see the particular factors from the above code stand for:
- $currentVersionId - implies the current version of the version_id field in the *_cl desk;
- $lastVersionId - is the last version of the equivalent index, taken from the mview_state table;
- $ids - will be the ids of the entities that need to be indexed.
From then on, each index becomes partially re-indexed in its own way. Now let's see if it is possible to include custom causes to MySQL dining tables and perform custom partial indexing. Let's check the \Magento\Framework\Mview\View::subscribe method:
The first series verifies whether incomplete indexing is enabled for the Mview index. Next, there is established a respected *_cl table. After that the cycle undergoes the list of all members and creates causes in the MySQL table. To add a custom view that will observe for changes in your Mview index tables you merely need to produce an mview.xml document in the module directory.
View more : product design tools
Let's describe one at a time what each debate is responsible for. For example, let's take a code test from the component Catalog-Permission:
This code creates the catalogpermissions_category_cl desk which is subscribed for changes in catalog_category_entity and catalog_category_entity_int desks' data. The info from entity_column - entity_id will be sent to the *_cl stand. This will result in the causes of the next type:
Re-indexing will be performed by the thing of the class field (start to see the $action variable in the aforementioned code). Nevertheless, you might have pointed out that we haven't used the registration_model field. This feature is saved in the <stand> field and it indicates the course which is responsible for creating triggers and their syntax. Certain causes is probably not as simple as identified above. In such cases one needs to use a custom model that is inherited from the default one. Here is a good example of such a model from Magento 2 EE:
Because you see, your body of the lead to differs from the trigger which we created the first time.
From the above example you may see how simple and tasteful a partial index is. You may redefine existing subscriptions with no problems (there have been such situations with the EE version when the designers simply forgot about the Staging module) as well as define your own subscriptions to work with custom indexes.