我已经看到一些与此相关的帖子，并亲自调查了相同的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 / pre / 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。
如果有人有时间调查 似乎 已实施的“回滚”和“卸载”过程并报告其发现，这对我也将有所帮助。
