enterprise_url_rewrite table - what does column “inc” save?

Question

I'm wondering what does "inc" means? In my particular case all rewrites do have set 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)

Thanks!

Answer 1

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

Enterprise_UrlRewrite_Model_Index_Action_Url_Rewrite_RefreshAbstract::_refreshUrlRewrite

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 parent::_getUrlRewriteSelectSql

• Enterprise_UrlRewrite_Model_Index_Action_Url_Rewrite_Redirect_Refresh_Row::_getUrlRewriteSelectSql
• Enterprise_UrlRewrite_Model_Index_Action_Url_Rewrite_Redirect_Refresh_Changelog::_getUrlRewriteSelectSql

Which is defined as Enterprise_UrlRewrite_Model_Index_Action_Url_Rewrite_Redirect_Refresh::_getUrlRewriteSelectSql

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 isCASE WHEN ur.inc IS NULL ORm.value= 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.