Таблица 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).Если приращение равно нулю, не применяйте никакого значения приращения, в противном случае объедините его с концом URL-адреса.Этот запрос вводится в логику шага 1, где он пытается _refreshUrlRewrite но потенциально с увеличением числа в конце.

В совокупности я думаю, что эта логика предназначена для отслеживания числа, которое применяется к концу URL-адреса при обнаружении дубликата.