qu'est-ce que mview dans magento2?

Tout d'abord ce que je sais:

La gestion des index est utile pour augmenter les performances du magasin.

EAV a un inconvénient: il stockera les données dans différentes tables, de sorte que la récupération des données prend du temps.

Afin que nous stockions les données dans une seule table. lorsque les données sont modifiées, nous mettrons à jour cette table unique (rien que la mise à jour de l'indexation)

mysql trigger: effectuer des actions de requête basées sur une insertion / mise à jour / suppression de table.

Ainsi, Magento utilisant un déclencheur par exemple lorsque le prix est mis à jour, il sera entity_idstocké dans la table du journal des modifications.

il y a une instruction dans devdocs pour implémenter les déclencheurs magento2 en utilisant Magento/Framework/Mview.

pouvez-vous expliquer le flux de cette fonctionnalité?

Je veux dire ce qui est view, action, processoretc?

Dans la documentation officielle: https://devdocs.magento.com/guides/v2.3/extension-dev-guide/indexing.html il y a le stement:

`Allows tracking database changes for a certain entity (product, category and so on) and running change handler.
Emulates the materialized view technology for MySQL using triggers and separate materialization process (provides executing PHP code instead of SQL queries, which allows materializing multiple queries).`

MView signifie Materialized View, qui est un instantané de la base de données à un moment donné. https://en.wikipedia.org/wiki/Materialized_view Pourquoi aurions-nous besoin de dupliquer des tableaux. Les indexeurs sont coûteux à exécuter, en particulier lorsqu'il y a du trafic sur les pages de catégorie, les clients passent des commandes et les administrateurs enregistrent les produits. Lors de l'enregistrement du produit, le cache est invalidé (hors sujet). En cas d'indexeur de stock, avant de terminer l'exécution, il envoie les identifiants d'entité concernés en tant que balises de cache à nettoyer (type de cache pleine page). Dans les catégories Magento 2.0, les identifiants des produits achetés sont envoyés. Dans Magento 2.1, les identifiants des produits sont envoyés.

Il y a 2 tables MySQL qui conservent les codes et les états de l'indexeur:

• indexer_state
• mview_state

mview_statefonctionne avec Update by Scheduledans Admin> Système> Gestion de l'indexeur

Update by Schedule rend les indexeurs à exécuter dans cron.

Il y a 3 entrées dans Magento_Indexer/etc/contab.xml:

<group id="index">
    <job name="indexer_reindex_all_invalid" instance="Magento\Indexer\Cron\ReindexAllInvalid" method="execute">
        <schedule>* * * * *</schedule>
    </job>
    <job name="indexer_update_all_views" instance="Magento\Indexer\Cron\UpdateMview" method="execute">
        <schedule>* * * * *</schedule>
    </job>
    <job name="indexer_clean_all_changelogs" instance="Magento\Indexer\Cron\ClearChangelog" method="execute">
        <schedule>0 * * * *</schedule>
    </job>
</group>

• indexer_reindex_all_invalidest exécuté indexer_state. Il est toujours nécessaire d'exécuter des indexeurs «normaux» dans cron
• indexer_update_all_views est exécuté sur mview_state
• indexer_clean_all_changelogs - efface les journaux des modifications utilisés par mview_state

Notez que les tâches du groupe indexeur cron exécuter dans un processus php séparé, tel que déclaré dans etc/contab_groups.xml: <use_separate_process>1</use_separate_process>.

Les tables du journal des modifications sont: [indexer name]_cl(suffixées de _cl). par exemple cataloginventory_stock_cl. Si vous avez des indexeurs définis pour Update by Scheduleet enregistrez un produit dans admin, vous verrez le entity_idde ce produit dans ce tableau. C'est un grand cercle, je pense que passer commande ou créer un envoi ajoutera ici une entrée également.

Quelqu'un a fourni un exemple dans devdoc officiel sur la façon de créer de nouvelles vues matérialisées et quelles sont les méthodes d'interface requises (ne tenez pas compte de la déclaration ci-dessus concernant les commandes dans l'extrait de code ci-dessous):

<?php
<VendorName>\Merchandizing\Model\Indexer;
class Popular implements \Magento\Framework\Indexer\ActionInterface,   \Magento\Framework\Mview\ActionInterface
{
public function executeFull(); //Should take into account all placed orders in the system
public function executeList($ids); //Works with a set of placed orders (mass actions and so on)
public function executeRow($id); //Works in runtime for a single order using plugins
public function execute($ids); //Used by mview, allows you to process multiple placed orders in the "Update on schedule" mode
}

Cela aura un sens: //public function execute($ids); Used by mview, allows you to process multiple **entities** in the "Update on schedule" mode } où le $idsparamètre a les identifiants d'entités des *_cltables.

Quel est le lien entre l'invalidation du cache et les indexeurs. Les pages de catégories sont désormais mises en cache sur toute la page (cache de page complet intégré ou via Vernis).

Il y a \Magento\Indexer\Model\Processor\InvalidateCache::afterUpdateMview:

/**
 * Update indexer views
 *
 * @param \Magento\Indexer\Model\Processor $subject
 * @return void
 * @SuppressWarnings(PHPMD.UnusedFormalParameter)
 */
public function afterUpdateMview(\Magento\Indexer\Model\Processor $subject)
{
    if ($this->moduleManager->isEnabled('Magento_PageCache')) {
        $this->eventManager->dispatch('clean_cache_after_reindex', ['object' => $this->context]);
    }
}

Retour à Magento\Indexer\Cron\UpdateMview::execute():

/**
 * Regenerate indexes for all invalid indexers
 *
 * @return void
 */
public function execute()
{
    $this->processor->updateMview();
}

Magento\Indexer\Model\Processor::updateMview():

/**
 * Update indexer views
 *
 * @return void
 */
public function updateMview()
{
    $this->mviewProcessor->update('indexer');
}

Il app/etc/di.xmly a:

<preference for="Magento\Framework\Mview\ProcessorInterface" type="Magento\Framework\Mview\Processor" />


/**
 * Materialize all views by group (all views if empty)
 *
 * @param string $group
 * @return void
 */
public function update($group = '')
{
    foreach ($this->getViewsByGroup($group) as $view) {
        $view->update();
    }
}

Magento\Framework\Mview\ViewInterface

/**
 * Materialize view by IDs in changelog
 *
 * @return void
 * @throws \Exception
 */
public function update();

app/etc/di.xml

 <preference for="Magento\Framework\Mview\ViewInterface" type="Magento\Framework\Mview\View" />

Il Magento\Framework\Mview\View::update()y a:

$action = $this->actionFactory->get($this->getActionClass());
$this->getState()->setStatus(View\StateInterface::STATUS_WORKING)->save();
..
$action->execute($ids);
..

Si vous recherchez dans le vendor/répertoire pour Magento\Framework\Mview\ActionInterfacevous trouverez par exemple ceci:

Dans \Magento\CatalogInventory\Model\Indexer:

class Stock implements \Magento\Framework\Indexer\ActionInterface, \Magento\Framework\Mview\ActionInterface

Dans cette classe il y a:

/**
 * Execute materialization on ids entities
 *
 * @param int[] $ids
 *
 * @return void
 */
public function execute($ids)
{
    $this->_productStockIndexerRows->execute($ids);
}

Et il semble qu'il retourne à la classe «normale» des indexeurs, la méthode «execute» qui est utilisée par MView.

À propos du nettoyage du cache après Stock Indexer. Lorsqu'une commande est passée à la caisse, les quantités sont soustraites à l'aide de cet observateur:\Magento\CatalogInventory\Observer\SubtractQuoteInventoryObserver

$itemsForReindex = $this->stockManagement->registerProductsSale(
    $items,
    $quote->getStore()->getWebsiteId()
);

De plus, un autre observateur déclenche l'indexeur (mais pas directement sur Mview / Indexer by Schedule): \Magento\CatalogInventory\Observer\ReindexQuoteInventoryObserver

if ($productIds) {
    $this->stockIndexerProcessor->reindexList($productIds);
}

Dans le cas de Mview, lorsque les nouvelles quantités sont soustraites SubtractQuoteInventoryObserver, le déclencheur MySQL (créé pour Mview) insérera une ligne dans cataloginventory_stock_cl, marquant qu'une réindexation (stock et texte intégral) doit être effectuée pour les ID de produit achetés. Il existe de nombreux déclencheurs MySQL créés pour Mview. Voyez-les tous avec SHOW TRIGGERS;.

Lorsqu'un produit est en rupture de stock après le paiement, vous verrez 2 lignes insérées dans ce tableau (Magento enregistre 2 fois l'article en stock dans ces 2 observateurs).

Lorsque cron exécute l'indexeur de stock en mode Mview, les identifiants de produit affectés (dans M2.1) ou les identifiants de catégories (dans M2.0) sont envoyés au cache clean en tant que balises de cache. Par cache, je veux dire le type de cache pleine page. Exemple: catalog_product_99ou autre format de balise de cache selon la version de Magento. De même lorsque Mview n'est pas activé.

\Magento\CatalogInventory\Model\Indexer\Stock\AbstractAction::_reindexRows

...
$this->eventManager->dispatch('clean_cache_by_tags', ['object' => $this->cacheContext]);

Et Magento_PageCache a un observateur \Magento\PageCache\Observer\FlushCacheByTagsqui nettoiera le type de cache pleine page par des balises. Il le fait pour le cache pleine page intégré. Le code relatif au vernis est entré \Magento\CacheInvalidate\Observer\InvalidateVarnishObserver.

Il existe une extension gratuite qui refusera le nettoyage du cache sur les produits encore en stock après le paiement du client:

https://github.com/daniel-ifrim/innovo-cache-improve

Nettoyage du cache uniquement sur les produits en rupture de stock après l'introduction de la commande dans Magento 2.2.x. Tu vois \Magento\CatalogInventory\Model\Indexer\Stock\CacheCleaner.

Je pense que l'exécution de cron pour l'indexeur dans Admin > Stores > Configuration > Advanced > System > Cron configuration options for group: indexdevrait être définie sur plus de 1 minute.

Le mview.xmlest utilisé avec indexer.xmlpour configurer les indexeurs.

Le mview.xmlfichier déclare:

• ID de vue de l'indexeur
• classe indexeur
• la base de données table les pistes d'indexation
• quelles données de colonne sont envoyées à l'indexeur

Le indexer.xmlfichier déclare:

• ID d'indexeur
• nom de classe d'indexeur
• titre de l'indexeur
• description de l'indexeur
• ID de vue de l'indexeur

Vous pouvez trouver plus d'informations sur la déclaration d'indexeur personnalisé ici: Indexeur personnalisé sur Magento2

D'après ce que j'ai compris, il y a deux choses différentes ici:

• L'indexeur du Magento_Indexermodule
• La Mview à partir de Magento\Framework\Mviewlaquelle émule la vue matérialisée pour MySQL à l'aide de déclencheurs.

Voici quelques informations captivantes de la documentation officielle

Types d'indexation

Chaque index peut effectuer les types d'opérations de réindexation suivants:

• Réindexation complète, ce qui signifie la reconstruction de toutes les tables de base de données liées à l'indexation.

• La réindexation complète peut être causée par diverses choses, notamment la création d'une nouvelle boutique en ligne ou d'un nouveau groupe de clients. Vous pouvez éventuellement réindexer complètement à tout moment à l'aide de la ligne de commande.

• Réindexation partielle, ce qui signifie la reconstruction des tables de base de données uniquement pour les éléments qui ont changé (par exemple, la modification d'un attribut ou d'un prix de produit unique).

Le type de réindexation effectué dans chaque cas particulier dépend du type de modifications apportées dans le dictionnaire ou dans le système. Cette dépendance est spécifique à chaque indexeur.

Concernant le Workflow, il s'agit ici d'une réindexation partielle:

La référence du document Magento est déjà là, donc je saute cette partie.
Magento a implémenté la vue matérialisée dans 2.0 qui suit les changements pour tous les indexeurs. Chaque indexeur a une _cltable qui obtient entity_idet un auto_increment version_iddes déclencheurs ajoutés sur les tables principales.
Lorsque le travail cron s'exécute, l'indexeur est le dernier version_idpour chaque vue de la mview_statetable et indexe les prochaines entités disponibles dans la _cltable.
La réindexation était un casse-tête jusqu'à 1.9.xx et avec un énorme catalogue, elle ralentissait toujours le système.
Dans Magento 2.0, l'indexeur ne met à jour que les informations d'entité particulières sur les tables d'indexeur plutôt que de réindexer des données entières. Cela permet de faire rouler la balle sans ralentir le serveur.
Remarque: la vue matérialisée n'est pas prise en charge dans mysql, donc dans Magento, elle est gérée par du code PHP et fonctionne de manière similaire à la vue matérialisée qui est une fonctionnalité du SGBD de niveau entreprise comme oracle.