Автоматический мгновенный откат является важной особенностью механизмов развертывания корпоративного уровня. В настоящее время достичь этого невозможно, используя встроенные инструменты установки Magento.
Учитывая, что механизм core_resource Magento позволяет последовательно выполнять сценарии установки для установки или обновления модулей (через выполнение SQL, а также PHP), кажется логичным ИМХО, что он должен поддерживать тот же процесс в обратном порядке.
Теперь некоторые очевидные причины не поддерживать его:
Было бы сложно, чтобы скрипты отката были независимыми (и, возможно, идемпотентными?). Я не вижу, чтобы это было веской причиной, чтобы избежать этой функции, это в лучшем случае оправдание.
Другие модули могут иметь зависимости от установленного модуля. Для обозначения этих связей можно использовать узел xml объявления модуля <depends/> .
Разработчик может захотеть временно отключить модуль без полной деинсталляции. Это может потребовать новый статус в объявлении xml объявления <active/> .
Интересует ваши мысли.
JD
Я видел некоторые публикации в отношении таких и сам исследовал те же сценарии для развертывания SQL. Я должен был бы согласиться с тем, что в классе Enterprise Magento должен быть встроен такой тип функциональности. Хорошая новость – это, по крайней мере, в НЕКОТОРНОЙ форме или моде, насколько это полно, я не уверен. Вот пример откат при исключении:
try { $write = Mage::getSingleton('core/resource')->getConnection('core_write'); $write->beginTransaction(); // do stuff here $write->commit(); } catch (Exception $e) { mage::log(__METHOD__ . ':' . __LINE__ . ': Rollback happened.'); $write->rollback(); }
Теперь, если вы посмотрите на приложение / код / ядро / Mage / Core / Model / Resource / Setup.php, вы найдете немало интересных методов. В частности: _getModifySqlFiles , _rollbackResourceDb и _modifyResourceDb .
_modifyResourceDb – самое интересное для меня, так как $ actionType здесь может быть откат и деинсталляция – также обратите внимание, что вы также можете использовать файлы PHP для ваших файлов настроек.
// Read resource files $arrAvailableFiles = array(); $sqlDir = dir($sqlFilesDir); while (false !== ($sqlFile = $sqlDir->read())) { $matches = array(); if (preg_match('#^'.$resModel.'-'.$actionType.'-(.*)\.(sql|php)$#i', $sqlFile, $matches)) { $arrAvailableFiles[$matches[1]] = $sqlFile; } }
После выполнения этого кода:
$arrModifyFiles = $this->_getModifySqlFiles($actionType, $fromVersion, $toVersion, $arrAvailableFiles);
Но heres, где я предполагаю, что основные разработчики Magento заблудились в недрах модели ресурсов EAV и просто оставили ее частично завершенной.
protected function _getModifySqlFiles($actionType, $fromVersion, $toVersion, $arrFiles) { $arrRes = array(); switch ($actionType) { case 'install': case 'data-install': ... case 'rollback': break; case 'uninstall': break; } return $arrRes; }
У меня не было возможности действительно проверить это выше, но только из моих первоначальных исследований ORM, которые являются magento и Autoloading, а также вклада другого разработчика в его результаты.
В конечном итоге это было бы идеально, если бы мы могли сохранить все наши изменения, по крайней мере, модульно в рамках системы, контролируемой версиями. Очевидно, что огромные массивы данных, которые необходимо импортировать, не должны управляться таким образом, но для этих небольших инкрементных изменений я хочу нажать на этап, производственный тест, и если он не удастся вернуть его на одну версию, и все вернется к норме.
Очевидно, что единственное идеальное решение для развертывания с таким количеством клиентов, которые имеют разные требования и потребности, но общий способ сделать это поможет при развертывании кода / SQL. Как ни парадоксально, что Enterprise имеет стадию CMS и способность к модульной разработке кода, но БД не получила столько любви.
Существует связанный с этим вопрос, который отмечает, как в настоящее время мы делаем это с некоторыми специализированными сценариями, которые «на дому», которые по существу делают:
Выполнение MySQLDump или резервное копирование, а затем выполнение замены на BASE_URL в файле SQL.
Рекомендации по развертыванию Magento
Еще одним инструментом для просмотра будет Phing .
Если у кого есть время, чтобы исследовать процессы «откат» и «удаление», которые, как представляется, будут реализованы и сообщать о своих выводах, было бы полезно и мне.
Мне напомнили о собственном вопросе, где Иван Чепурский сказал вам:
@ Джонатан надеется, что Magento 2.0 будет более дружественным для разработчиков, особенно в плане обновления базы данных. Но, конечно, это будет просто расширен Zend_Db. Использование Doctrine 2.0 orm решило бы эту проблему, но для этого требуется переписать Magento с нуля 🙂
Я не знаю Doctrine, но из чтения его отображения схема описывается в комментариях PHPDoc для классов (предположительно полученных отражением ), которые затем преобразуются в запросы прозрачно. Нет необходимости в настройках скриптов. Это должно означать, что откат аналогичен отказу, установке предыдущих классов версии и их комментариям, а остальное просто происходит.
Зная Magento, они, вероятно, не вернутся и не нарушат старый код, а вместо этого предложит альтернативный метод установки с использованием инкрементных XML-файлов – хотя и без пространства имен. Откат версии здесь означал бы превращение разницы, как описано в каждом файле.
Я тоже предпочел бы это, так как это означает, что такие инструкции, как вставка записей по умолчанию, были бы возможны, я не думаю, что Doctrine управляет. И он сосуществует с версиями, предшествующими изменению. Вы собираетесь сделать запрос функции ?
Номера версий в <depends/> кажутся логичными.
У меня действительно нет третьего момента, но я хотел закончить набор. : D
Редактировать:
Я забыл ответить на вопрос. Нет, нет причин, по которым Magento не должен поддерживать понижение, по крайней мере, если они не захотят приложить усилия.
Примечание. Возможно, это не применимо к Magento.
Обычно я просматриваю обновления приложений баз данных, охватывающие две основные области: 1. база данных 2. кода.
Обновления кода легко откат. Обычно я управляю этим отдельно от кода обновления / управления приложениями. Обычно я использую файловую систему ОС, чтобы предоставить мне функциональность «мгновенного отката». Если речь идет о резервных копиях базы данных, все становится еще сложнее. Аналогичный подход можно использовать и с базой данных. Однако это было бы реалистично только в тестовой системе.
Если это только откат кода, о котором вы беспокоитесь, я бы использовал что-то внешнее из самого приложения для управления этим. Я думаю, это можно считать снимком.
Если Magento не поддерживает это из коробки, я не думаю, что было бы разумно применить его. Похоже, что основное требование состоит в том, что, если не планировать и кодировать с самого начала, будет довольно сложно реализовать.