Table Enterprise_url_rewrite - que sauvegarde la colonne « inc » ?

Question

Je me demande ce que signifie "inc" ?Dans mon cas particulier, toutes les réécritures ont défini inc=1.

mysql> describe enterprise_url_rewrite;
+----------------+----------------------+------+-----+---------+----------------+
| Field          | Type                 | Null | Key | Default | Extra          |
+----------------+----------------------+------+-----+---------+----------------+
| url_rewrite_id | int(10) unsigned     | NO   | PRI | NULL    | auto_increment |
| request_path   | varchar(255)         | NO   | MUL | NULL    |                |
| target_path    | varchar(255)         | NO   |     | NULL    |                |
| is_system      | smallint(5) unsigned | NO   |     | NULL    |                |
| guid           | varchar(32)          | NO   |     | NULL    |                |
| identifier     | varchar(255)         | NO   | MUL | NULL    |                |
| inc            | int(10) unsigned     | NO   |     | 1       |                |
| value_id       | int(10) unsigned     | NO   | MUL | NULL    |                |
| store_id       | smallint(5) unsigned | NO   |     | NULL    |                |
| entity_type    | smallint(5) unsigned | NO   |     | NULL    |                |
+----------------+----------------------+------+-----+---------+----------------+
10 rows in set (0.00 sec)

Merci!

Answer 1

Ce qui suit se concentre sur les URL de produits stockées dans ce tableau, mais il en va de même pour les catégories.C'est simplement parce que les produits sont ce que je déboguais, et pour des exemples simples.

Il n'y a que deux endroits où je peux trouver cette valeur utilisée

1.Incrémenter le compteur

Enterprise_UrlRewrite_Model_Index_Action_Url_Rewrite_RefreshAbstract::_refreshUrlRewrite

Dans cette méthode, il y a une requête pour mettre à jour la réécriture de l'URL, elle contient un peu de code PHP comme :

$insert .= sprintf(' ON DUPLICATE KEY UPDATE %1$s = %1$s + 1',
$this->_getTable('enterprise_urlrewrite/url_rewrite') . '.inc');

Cela permet de générer une requête vraiment amusante comme

INSERT INTO `enterprise_url_rewrite` (`request_path`, `target_path`, 
`guid`, `is_system`, `identifier`, `value_id`, `store_id`, 
`entity_type`) SELECT `uk`.`value` AS `request_path`, 
CONCAT('catalog/product/view/id/', uk.entity_id) AS `target_path`, 
'66af826f9f0df53191c06afe93c03159' AS `guid`, 1 AS `is_system`, 
`uk`.`value` AS `identifier`, `uk`.`value_id`, `uk`.`store_id`, 3 AS
`entity_type` FROM `catalog_product_entity_url_key` AS `uk` WHERE 
(uk.entity_id IN ('19472')) ON DUPLICATE KEY UPDATE 
enterprise_url_rewrite.inc = enterprise_url_rewrite.inc + 1

La chose à noter est juste à la fin, cela incrémentera le compteur s'il y a des erreurs de contrainte d'intégrité.

Dans le cas où des produits rentrent dans cette requête, cela signifie qu'après cette requête il vous manquera l'entrée correspondante dans enterprise_catalog_product_rewrite.Vous pouvez vérifier quels produits manquent en effectuant une recherche select entity_id, sku from catalog_product_entity where entity_id not in(select product_id from enterprise_catalog_product_rewrite);.

Ce sera parce que le chemin de la requête existe déjà dans enterprise_url_rewrite pour le type d'entité/magasin donné, vous devriez voir le inc le numéro est incrémenté à chaque fois que cette requête est exécutée en cas de violation de contrainte pour cette entité.

Cette logique se trouve dans la classe abstraite et cette méthode n'est remplacée dans aucune de ses méthodes enfants, ce qui signifie qu'elle est cohérente pour

• Journal des modifications (Mview / Mise à jour selon le calendrier)
• Ligne (mise à jour lors de l'enregistrement)
• Actualiser (réindexation complète)

Cela signifie que toutes les réindexations d'URL ont la même logique de repli : "en cas d'erreur, incrémentez le compteur".

2.Utilisation de la valeur d'incrément

Les deux appels suivants parent::_getUrlRewriteSelectSql

• Enterprise_UrlRewrite_Model_Index_Action_Url_Rewrite_Redirect_Refresh_Row::_getUrlRewriteSelectSql
• Enterprise_UrlRewrite_Model_Index_Action_Url_Rewrite_Redirect_Refresh_Changelog::_getUrlRewriteSelectSql

Qui est défini commeEnterprise_UrlRewrite_Model_Index_Action_Url_Rewrite_Redirect_Refresh::_getUrlRewriteSelectSql

C'est le seul autre endroit que je vois qui utilise le .inc valeur dans la base de données.

Ceux-ci appellent essentiellement un insertFromSelect déclaration, et cela ressemble vraiment à :

SELECT CONCAT(r.identifier, CASE  WHEN ur.inc IS NULL OR `m`.`value` = 1 THEN '' 
ELSE CONCAT('-', ur.inc) END) AS `request_path`, `r`.`target_path`,
'65912c647bc5f65fc0f59df5f6477d05' AS `guid`, 0 AS `is_system`, 
CONCAT(r.identifier, CASE  WHEN ur.inc IS NULL OR `m`.`value` = 1 
THEN '' ELSE CONCAT('-', ur.inc) END) AS `identifier`, 
`r`.`redirect_id` AS `value_id`, `r`.`store_id`, 1 AS `entity_type`
FROM `enterprise_url_rewrite_redirect` AS `r` LEFT JOIN
enterprise_url_rewrite` AS `ur` ON ur.identifier = r.identifier
AND ur.store_id = r.store_id AND ur.entity_type = 1 LEFT JOIN 
`enterprise_index_multiplier` AS `m` ON ur.identifier IS NOT NULL

L'élément clé que je vois estCASE WHEN ur.inc IS NULL ORm.valeur= 1 THEN '' ELSE CONCAT('-', ur.inc) END).Si l'incrément est nul, n'appliquez aucune valeur d'incrément, sinon concaténez-la à la fin de l'URL.Cette requête est introduite dans la logique de l'étape 1, où elle tente de _refreshUrlRewrite mais potentiellement avec un incrément de numéro à la fin.

Dans l’ensemble, je pense que cette logique est en place pour garder une trace du numéro à appliquer à la fin de l’URL lorsqu’un doublon est rencontré.