enterprise_url_rewrite 表 - “inc”列保存什么？

Question

我想知道“inc”是什么意思？在我的特定情况下，所有重写都设置了 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)

谢谢！

Answer 1

以下内容均重点关注此表中存储的产品 url，但这同样适用于类别。这只是因为产品就是我正在调试的产品，并且是简单的示例。

我只能在两个地方找到这个值

1.增加计数器

Enterprise_UrlRewrite_Model_Index_Action_Url_Rewrite_RefreshAbstract::_refreshUrlRewrite

在该方法中，有一个更新 url 重写的查询，它有一些 PHP 代码，例如：

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

这有助于生成一个非常有趣的查询，例如

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

需要注意的是最后，如果存在任何完整性约束错误，这将增加计数器。

如果产品进入此查询，则意味着在此查询之后您将缺少相应的条目 enterprise_catalog_product_rewrite. 。您可以通过搜索来查看缺少哪些产品 select entity_id, sku from catalog_product_entity where entity_id not in(select product_id from enterprise_catalog_product_rewrite);.

这是因为请求路径已经存在于 enterprise_url_rewrite 对于给定的实体类型/商店，您应该看到 inc 如果该实体存在约束违规，则每次运行此查询时数字都会增加。

该逻辑位于抽象类中，并且该方法不会在其任何子方法中被重写，这意味着它对于

• 变更日志（Mview / 按计划更新）
• 行（保存时更新）
• 刷新（完全重新索引）

这意味着 url 的所有重新索引都具有相同的后备逻辑“如果错误，则递增计数器”。

2.使用增量值

以下两个调用 parent::_getUrlRewriteSelectSql

• Enterprise_UrlRewrite_Model_Index_Action_Url_Rewrite_Redirect_Refresh_Row::_getUrlRewriteSelectSql
• Enterprise_UrlRewrite_Model_Index_Action_Url_Rewrite_Redirect_Refresh_Changelog::_getUrlRewriteSelectSql

其定义为Enterprise_UrlRewrite_Model_Index_Action_Url_Rewrite_Redirect_Refresh::_getUrlRewriteSelectSql

这是我能看到的唯一使用 .inc 数据库中的值。

这些基本上称为 insertFromSelect 声明，它看起来真的很粗糙：

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

我看到的关键部分是CASE WHEN ur.inc IS NULL OR米.价值= 1 THEN '' ELSE CONCAT('-', ur.inc) END). 。如果增量为 null，则不应用任何增量值，否则将其连接到 URL 的末尾。该查询被输入到步骤 1 的逻辑中，它尝试 _refreshUrlRewrite 但最后可能会有数字增量。

所有这些都放在一起，我认为这个逻辑已经到位，可以跟踪遇到重复项时应用于 url 末尾的数字。