Magento数据库升级是否通过“交​​易”进行？

我们有这个问题的atm：

客户将其商店从CE 1.4升级到CE 1.8。在我们的开发机器上，文件升级进展顺利，数据库升级也进展顺利。

当我们尝试在客户端的实时计算机上升级客户端的实时数据库（将1.8-Magento连接到数据库并在浏览器中打开它）时，该过程似乎运行了一段时间，并以500错误结束。

PHP错误日志为空；由于它是共享主机，因此我们无法更改apache或mysql设置；主机托管者尽管“专门的im magento托管”，但不愿意更改设置，并告诉我可以通过在出现500错误时重复刷新浏览器窗口来完成数据库升级，因为magento随后将以较小的步骤进行升级。这可能会持续几个小时。

我现在的问题是：
-这是真的吗？我认为数据库升级的sql语句将包装在事务中，因此如果出现任何问题，它们可以回滚。
-答案是否可以暗示我可以在代码中查找该问题的答案？

谢谢你的时间！

这是真的？我认为数据库升级的sql语句将包装在事务中，因此如果出现任何问题，它们可以回滚。

您的工程本能是健全的，但是在业务启动编程的现实世界中发生的事情却更加复杂/丑陋。

Magento的设置资源系统不会在事务中包装单个脚本。造成这种情况的原因很多，但我一直认为主要的原因是Magento明确地与MySQL捆绑在一起，并且MySQL中的许多/大多数数据定义语句（ALTER TABLE等）都会导致隐式提交。

虽然您会发现单个设置资源有时会使用事务。

#File: app/code/core/Mage/Sales/sql/sales_setup/mysql4-upgrade-1.3.99-1.4.0.0.php
$installer->getConnection()->beginTransaction();
$installer->run("
        UPDATE {$installer->getTable('sales_flat_order')} AS o, {$installer->getTable('sales_order_entity_varchar')} AS od
    //...    

系统本身只是运行脚本，并希望达到最佳效果。

如果您对运行这些资源的代码感兴趣，那么最好的起点应该在这里

#File: app/code/core/Mage/Core/Model/Resource/Setup.php
protected function _modifyResourceDb($actionType, $fromVersion, $toVersion)
{
    //...
}

该_modifyResourceDb方法是一种包含实际设置资源脚本的方法

#File: app/code/core/Mage/Core/Model/Resource/Setup.php
case 'php':
    $conn   = $this->getConnection();
    $result = include $fileName;
    break;
case 'sql':
    $sql = file_get_contents($fileName);
    if (!empty($sql)) {

        $result = $this->run($sql);
    } else {
        $result = true;
    }
    break;

解决您的问题的一个非常有技巧的方法是临时的core-hack / code-pool-override，在5-10个include之后明确退出，然后重新运行它。这将减少安装资源脚本中途失败的机会。

一个更好的解决方案是一个自定义脚本，该脚本是我的个人“也许一天”项目，该脚本使用Magento核心方法检查需要应用的更新，列出更新，并让用户逐个运行它们。