Подтвердить что ты не робот

Как новый URL-адрес Magento1.13 EE перезаписывает работу/Как новые таблицы базы данных связаны друг с другом?

Я играю с кодом Magento 1.13 в течение нескольких часов, и мне сложно понять, что они сделали с переписанием URL. Я надеялся, что тот, кто заглянул в это, мог указать мне в правильном направлении.

Я заметил, что core_url_rewrite больше не используется (или по крайней мере по умолчанию он пуст, и все новые продукты и категории, которые я добавляю, не отражаются в таблице core_url_rewrite). Вместо этого они добавляются в новую таблицу enterprise_url_rewrite.

Это было довольно просто, однако я заметил добавление еще нескольких других таблиц (например, enterprise_url_rewrite_category_cl, enterprise_url_rewrite_product_cl, enterprise_url_rewrite_redirect_cl, enterprise_url_rewrite_redirect_rewrite). Я отменил проектирование таблиц с помощью MySQL Workbench, и я придумал следующую диаграмму EER:

enter image description here

В приведенной выше диаграмме EER не показано соединение между enterprise_url_rewrite_redirect и enterprise_url_rewrite, но есть (по крайней мере, я предполагаю) связь между двумя управляемыми в таблице enterprise_url_rewrite_redirect_rewrite. Мои вопросы касаются того, что делают другие таблицы. У каждого из них есть version_id как первичный ключ и внешний ключ redirect_id или entity_id. Я предполагаю, что внешний ключ enterprise_url_rewrite_redirect_cl относится к первичному ключу enterprise_url_rewrite_redirect.

Мой первый вопрос заключается в том, что цель этой таблицы даже есть? Я не понимаю, как это может быть полезно. Я сделал широкомасштабный поиск проекта для таблицы и не смог найти, где он даже создается, а не используется. Простите меня, если ответ на этот вопрос очевиден.

Мой второй вопрос связан с таблицами enterprise_url_rewrite_product_cl и enterprise_url_rewrite_category_cl. Кажется, что эти две таблицы имеют entity_id. Мне было интересно, есть ли у кого-нибудь представление о том, что могут означать эти объекты_объектов?

Я также заметил из кода, что типичный способ доступа к моделям был изменен. Например, строка 781 Enterprise/AdminGws/Model/Controllers.php имеет следующее изменение кода:

From:

$object = Mage::getModel('core/url_rewrite')->load($id);

To:

$object = Mage::getSingleton('core/factory')->getUrlRewriteInstance()->load($id);

Теперь из Mage_Core_Model_Factory:

const XML_PATH_URL_REWRITE_MODEL = 'global/url_rewrite/model';
. . .
public function getUrlRewriteInstance()
{
    return $this->getModel($this->getUrlRewriteClassAlias());
}
. . .
    public function getUrlRewriteClassAlias()
{
    return (string)$this->_config->getNode(self::XML_PATH_URL_REWRITE_MODEL);
}

Мы видим, что путь XML является глобальным /url _rewrite/model. Если мы посмотрим на соответствующий файл Config.xml:

    <url_rewrite>
        <model>core/url_rewrite</model>
    </url_rewrite>

Наконец, изучая Mage/Core/Model/Url/Rewrite.php, я нашел следующие две функции:

 /**
 * Implement logic of custom rewrites
 . . . 
 * @deprecated since 1.7.0.2. Refactored and moved to Mage_Core_Controller_Request_Rewrite
 */

public function rewrite (...) {.,.

и

/**
 * Prepare and return QUERY_STRING
. . .
 * @deprecated since 1.7.0.2. Refactored and moved to Mage_Core_Controller_Request_Rewrite
 */
protected function_getQueryString() { . . .

Комментарии, похоже, подразумевают, что класс Mage_Core_Controller_Request_Rewrite должен существовать, но такого класса нет в Mage/Core/Controller/Request. Мне удалось обнаружить, что команда Magento, вероятно, ссылается на Mage_Core_Model_Url_Rewrite_Request (я предполагаю, что они просто забыли изменить комментарий. Я пытался пропустить это в отладчике, но он продолжает сбой по причинам, которые мне неизвестны. Я продолжаю получать следующий журнал:

a:5:{i:0;s:77:"Invalid method Mage_Core_Controller_Varien_Front::_getRequestPath(Array
(
)
)";i:1;s:611:"#0 xdebug://debug-eval(1): Varien_Object->__call('_getRequestPath', Array)
1 xdebug://debug-eval(1): Mage_Core_Controller_Varien_Front->_getRequestPath()
2 C:\user\emil\projects\magento\magento\app\code\core\Mage\Core\Controller\Varien\Front.php(1    67): Mage_Core_Controller_Varien_Front::dispatch()
3 C:\user\emil\projects\magento\magento\app\code\core\Mage\Core\Model\App.php(354): Mage_Core_Controller_Varien_Front->dispatch()
4 C:\user\emil\projects\magento\magento\app\Mage.php(683): Mage_Core_Model_App->run(Array)
5 C:\user\emil\projects\magento\magento\index.php(87): Mage::run('', 'store')
6 {main}";s:3:"url";s:14:"/magento/admin";s:11:"script_name";s:18:"/magento/index.php";s:4:"skin";s:7:"default";}

Вышеупомянутая проблема возникает только при входе в режим отладки. В целом, я попытался пройти через код, чтобы попытаться понять, как работает новый переписывающий, но в конечном итоге подошел с пустыми руками и застрял. Я искал Google и не придумал много. Мне было интересно, проведет ли кто-нибудь какое-либо исследование о том, как новая версия Magento EE работает для перезаписи URL еще?

Спасибо.

Эмиль

4b9b3361

Ответ 1

Трудно ответить на ваш вопрос, так как новый модуль перезаписи URL-адреса предприятия претерпел и все еще претерпевает значительные изменения. Ожидается стабильная версия со следующей версией (1.13.0.2), но до сих пор никто из основной команды Magento не может точно сказать, как будет выглядеть и работать модуль перезаписи.

Однако суть новой настройки заключается в том, что Magento теперь вытаскивает перезаписи из enterprise_url_rewrite, а все остальные таблицы, которые вы идентифицируете, используются для его восстановления во время процесса переиндексации.

Все выпущенные таблицы, заканчивающиеся на _cl, являются журналами изменений, привязанных к триггерам базы данных.