Connecting opportunities


HOW IT OPERATES: Magento 2 Partial indexing

Whoever has ever used Magento 1 or Magento 2 knows about such feature as index. It really is very important and useful since anything that is viewed on the frontend is related to index. Indexing by itself is a pretty long process that is why partial index has been available almost since the first version of Magento. Incomplete index means that people index not the whole report but only the part that is modified.

View more :

In Magento 2 EE there can be found 2 indexing methods: Update on Save and Update by Schedule. You are able to configure each method under Tools -> System -> Index Management. Each of them has its benefits and drawbacks. The main advantage of the Update on Save function is that it enables you to index data after saving the document. Quite simply, once you save a product in a category it becomes instantly on the frontend with all the changes as applied. However, the primary disadvantage is that it incredibly escalates the time for each operation to complete. That's the reason, to increase the process there has been introduced the Update by Schedule method. This feature lets you index data in the backdrop so there is absolutely no delay when you try to save any file. Everything is conducted asynchronously. The one minus of this method is that it may really have a while until the cron job starts indexing.

In this article we will describe how incomplete index works. Let's assume that our default method is Revise by Timetable, so, if not mentioned in any other case, the below information will concern exactly this method.

There is no special put in place the Magento code where you can find partial index entities ideals. The whole logic of incomplete index is conducted in a data source - via MySQL causes if to be more specific. For instance, the catalog_product_entity desk contains 3 sets off for the following events: AFTER Put in, AFTER UPDATE, AFTER DELETE

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

As seen from the above code the result in creates an archive in the *_cl tables in regards to a new entity. Let's check one particular *_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 suggests the current changes version quantity, as the entity_id field shows the ids of the entities which have to be indexed.

When indexing is started by the cron job, the version_id values in the *_cl dining tables are compared to the files from the mview_status table which contains the information about index variations and index position. Within the code area the logic is controlled by the Mview module which really is a area of the Magento framework.

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

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

View more :

Let's see what the parameters from the above code are a symbol of:

  • $currentVersionId - shows the current version of the version_id field in the *_cl stand;
  • $lastVersionId - is the last version of the related index, extracted from the mview_express table;
  • $ids - are 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 dining tables and perform custom incomplete indexing. Let's check the \Magento\Framework\Mview\View::subscribe method:

The first collection verifies whether incomplete indexing is allowed for the Mview index. Next, there is established a respective *_cl table. After that the cycle goes through the list of all members and creates causes in the MySQL stand. To include a custom view that will track for changes in your Mview index furniture you just need to make an mview.xml data file in the component directory.

View more : online product design tools

Let's describe one at a time what each discussion is in charge of. As an example, let's have a code sample from the module Catalog-Permission:

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

For catalog_category_entity:

Re-indexing will be performed by the thing of the class field (start to see the $action changing in these code). But you might have pointed out that we haven't used the membership_model field. This feature is documented in the <desk> field and it indicates the school which is in charge of creating causes and their syntax. Certain sets off may not be as simple as detailed above. In such cases 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:

Because you see, the body of the trigger differs from the trigger which we created the very first time.

From the above example you may see how simple and chic a partial index is. You are able to redefine existing subscriptions without the problems (there were such instances with the EE version when the developers simply forgot about the Staging module) as well as define your own subscriptions to work with custom indexes.

  • Service Provider
  • 0 answer(s)
  • hZWXmJhjmG-dl5iExaBkb-GkoGOYcFLJpMWoq4DHo5ifmatXc6xsmGVrUr98qKellJ--oJ_Tj6PNo5mMrs7PxrDF3N-wn8KdpcbWzNPUU3DZa55siJyl1JvYnqemiHCnbWVtb1qlm9CVcpPXoaWgfYeArlVx12ptnlqkkdTG0dSGn8Ogl2rcrJ6Uk52Gy5-pz6XfkdqvoMtan6hycKBXpaiZrKmhqKCHa6RqnHJYl6OnnNaslc2UWZ-rbmWch5WXlpqSiJ-jm3GehcPG2NWjlM-ViG3PcGChteE.

Have something to sell?

Join Anphabe for free to advertise your products/services and meet your next clients.


    There are no answers to this question yet.
Lazy Load...