The following all focuses on product urls stored in this table, however the same applies to categories as well. This is simply as products is what I was debugging, and for easy examples.
There are only two places that i can find this value used
1. Incrementing the counter
In that method there is a a query to update the url rewrite, it has a bit of PHP code like:
$insert .= sprintf(' ON DUPLICATE KEY UPDATE %1$s = %1$s + 1',
$this->_getTable('enterprise_urlrewrite/url_rewrite') . '.inc');
This helps generate a really fun looking query like
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
The thing to note is right at the end, this will increment the counter if there are any integrity constraint errors.
In the event of products going into this query, it means after this query you will be missing the corresponding entry in
enterprise_catalog_product_rewrite. You can check which products are missing by searching
select entity_id, sku from catalog_product_entity where entity_id not in(select product_id from enterprise_catalog_product_rewrite);.
This will be because the request path already exists in
enterprise_url_rewrite for the given entity type/store, you should see the
inc number increment every time this query is run if there is a constraint violation for that entity.
This logic is in the abstract class, and this method is not overridden in any of its children methods which means it is consistent for
- Changelog (Mview / Update on Schedule)
- Row (Update on save)
- Refresh (full reindex)
This means all reindexes for urls have the same fallback logic of "if error, increment counter".
2. Using the increment value
Both of the following call
Which is defined as
Is the only other place that I can see that uses the
.inc value in the database.
These basically call an
insertFromSelect statement, and it looks really gnarly like:
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
The key part that I see is
CASE WHEN ur.inc IS NULL ORm
= 1 THEN '' ELSE CONCAT('-', ur.inc) END). If increment is null then don't apply any increment value, otherwise concatenate it to the end of the URL. This query is fed into the logic of step 1, where it tries to
_refreshUrlRewrite but potentially with a number increment on the end.
All rolled together, I think this logic is in place to keep track of the number to apply to the end of the url when a duplicate is encountered.