Magento 是否有理由不支持模块卸载/降级

Question

自动即时回滚是企业级部署机制的一个重要特性。目前，使用 Magento 的内置安装工具无法实现此目的。

鉴于 Magento 的 core_resource 机制允许顺序执行用于安装或升级模块的设置脚本（通过 SQL 和 PHP 的执行），恕我直言，它应该反向支持相同的过程似乎是合乎逻辑的。

现在，有一些不支持它的明显原因：

1. 回滚脚本独立（并且可能是幂等的？）将具有挑战性。我不认为这是避免使用该功能的正当理由，这充其量只是一个借口。

2. 其他模块可能依赖于已安装的模块。模块的 xml 声明 节点可用于标记这些链接。

3. 开发人员可能希望暂时禁用模块而不进行完全卸载。这可能需要 xml 声明 节点中的新状态。

对您的想法感兴趣。
京东

Answer 1

我看过一些与此相关的帖子，并且自己也调查了 SQL 部署的相同场景。我不得不同意，企业级 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();
}

现在，如果您查看 app/code/core/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);

但我假设核心 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;
}

我还没有机会真正测试上述内容，但只是根据我对 magento 和自动加载的 ORM 的初步调查以及另一位开发人员对其发现的输入。

最终，如果我们能够在版本控制系统中至少以模块方式保留所有更改，那将是理想的。显然，需要导入的巨大数据集不应该以这种方式进行管理，但对于这些小的增量更改，我想将其推送到暂存、生产测试，如果失败，则将其拉回一个版本，一切都会恢复正常。

显然，对于如此多具有不同要求和需求的客户来说，没有一种理想的部署解决方案，但这样做的通用方法将有助于代码/SQL 部署。具有讽刺意味的是，Enterprise 拥有 CMS staging 和代码模块化开发的能力，但 DB 却没有得到那么多的喜爱。

有一个相关的问题指出，目前我们如何使用一些“自制”的专用脚本来完成此操作，这些脚本本质上是：

执行 MySQLDump 或备份，然后对 SQL 文件中的 BASE_URL 进行替换。

Magento 部署的最佳实践

另一个值得关注的工具是Phing。

如果有人有时间调查似乎实施的“回滚”和“卸载”流程并报告他们的发现也会对我有所帮助。

Answer 2

1. 我想起了我自己的问题，其中Ivan Chepurnyi 对你说：

   <块引用>

   @Jonathan 希望 Magento 2.0 对开发者更加友好，特别是在数据库升级方面。但当然它只会扩展 Zend_Db。使用Doctrine 2.0 orm可以解决这个问题，但是需要从头开始重写Magento:)

   我不知道 Doctrine，但通过阅读它的映射，该架构在类的 PHPDoc 注释中进行了描述（大概是由 reflection），然后透明地转换为查询。不需要安装脚本。这一定意味着回滚与降级相同，安装以前的版本类及其注释，剩下的就发生了。

   了解 Magento，他们可能不会返回并扰乱旧代码，而是提供使用增量 XML 文件的替代设置方法 - 尽管没有命名空间。此处回滚版本意味着反转每个文件中描述的差异。
   我也更喜欢这种方式，因为这意味着可以执行诸如插入默认记录之类的指令，而我认为 Doctrine 无法做到这一点。并且它与更改之前的版本共存。您要提出功能请求吗？

2. 中的版本号似乎合乎逻辑。

3. 我真的没有第三点，但我想完成这套。 :D

编辑：
我忘记回答问题了。不，Magento 没有理由不支持降级，至少如果他们愿意付出努力的话。

Answer 3

注意：这可能不适用于 Magento。

我通常认为数据库应用程序升级涵盖两个主要领域：1.代码2.数据库。

代码更新很容易回滚。我通常将其与应用程序升级/管理代码分开管理。我通常使用操作系统的文件系统来为我提供“即时回滚”功能。当涉及数据库回滚时，事情会变得更加复杂。人们也可以对数据库采取类似的方法。然而，这只有在测试系统上才现实。

如果您只关心代码回滚，我会使用应用程序本身外部的东西来管理它。我想它可以被认为是一个快照。

如果 Magento 不支持开箱即用的功能，我认为添加它并不明智。这似乎是一个相当核心的需求，如果从一开始就没有计划和编码，那么实现起来将相当棘手。