جدول 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 عند مواجهة نسخة مكررة.