我已经看到一些与此相关的帖子，并亲自调查了相同的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和Autoloading的ORM的初步调查以及其他开发人员对他的发现的投入中得出的结论。

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

显然，对于这么多具有​​不同需求的客户端而言，没有一种理想的部署解决方案，但是一种通用的实现方式将有助于代码/
SQL部署。具有讽刺意味的是，Enterprise拥有CMS暂存，并且具有代码模块化开发的能力，但是DB并没有获得如此多的关注。

有一个相关的问题，说明我们目前如何使用一些专门做的“自制”脚本来完成此工作：

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

可以查看的另一种工具是Phing。

如果有人有时间调查 似乎 已实施的“回滚”和“卸载”过程并报告其发现，这对我也将有所帮助。