Question

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

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

现在，一些明显的理由不支持它：

回滚脚本独立（并且可能是幂等的）会很有挑战性。我不认为这是避免该功能的正当理由，它充其量只是一个借口。
其他模块可能依赖于已安装的模块。模块的xml声明<depends/>节点可用于标记这些链接。
开发人员可能希望在不执行完全卸载的情况下暂时禁用模块。这可能需要xml声明<active/>节点中的新状态。

对你的想法感兴趣。
JD

Answer 1

我想起了question我自己Ivan Chepurnyi对你说的话：

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

我不知道Doctrine，但是通过阅读它的映射，PHPDoc对类的注释（可能由reflection获取）中描述了模式，然后将其透明地转换为查询。无需安装脚本。这必须意味着回滚与降级相同，安装以前的版本类及其注释，其余的只是发生。

了解Magento他们可能不会回头破坏旧代码，而是提供使用增量XML文件的替代设置方法 - 尽管没有命名空间。在这里回滚版本将意味着反转每个文件中描述的差异我也喜欢这种方式，因为它意味着插入默认记录等指令是可能的，我不认为Doctrine管理的东西。它与变更之前的版本共存。你打算做一个feature request吗？
<depends/>中的版本号似乎合乎逻辑。
我真的没有第三点，但我想完成这一套。：d

修改
我忘了回答这个问题。不，没有理由认为Magento不应该支持降级，至少不是因为他们愿意付出努力。

Answer 2

我已经看过一些关于此类的帖子，并且自己调查了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;
}

我没有机会真正测试上述内容，但仅仅是我对ORM的初步调查，即magento和自动加载，以及其他开发人员对他的调查结果的输入。

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

显然，没有一个理想的部署解决方案，因为有这么多客户有不同的要求和需求，但这样做的一般方法有助于代码/ SQL部署。具有讽刺意味的是，Enterprise具有CMS升级功能，以及代码模块化开发的能力，但DB并没有得到那么多的爱。

有一个相关的问题是注意到我们目前是如何使用一些专门的脚本“自酿”基本上做的：

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

Best practices for Magento Deployment

要查看的另一个工具是Phing。

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

Answer 3

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

我通常查看数据库应用程序升级，涵盖两个主要方面：1。代码2.数据库。

代码更新很容易回滚。我通常单独管理应用程序升级/管理代码。我通常使用操作系统的文件系统为我提供“即时回滚”功能。在涉及数据库回滚的地方，事情变得更加复杂。人们也可以对数据库采取类似的方法。但是，它只适用于测试系统。

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

如果Magento不支持开箱即用，我认为解决这个问题并不明智。这似乎是一个核心要求，如果从一开始就没有计划和编码，实施起来会相当棘手。

有没有理由说Magento不支持卸载/降级模块

3 个答案: