¿La actualización de la base de datos de Magento ocurre en una "transacción"?

Tenemos este problema atm:

Un cliente actualiza su tienda de CE 1.4 a CE 1.8. La actualización del archivo funcionó bien y la actualización de la base de datos también funcionó bien en nuestra máquina de desarrollo.

Cuando intentamos actualizar live-db del cliente en su máquina en vivo (conecta el 1.8-Magento a la base de datos y lo abre en el navegador), el proceso parece ejecutarse por un tiempo y termina en un error 500.

El registro de errores de PHP está vacío; como es un host compartido, no podemos cambiar la configuración de apache o mysql; el host, aunque "hosting especializado en magento im", no está dispuesto a cambiar la configuración y me dice que podría finalizar la actualización de la base de datos actualizando repetidamente la ventana del navegador cuando se produce el error 500, porque magento se actualizará en pequeños pasos . Esto podría continuar por horas.

Mi pregunta ahora es:
¿Es esto cierto? Pensé que las sentencias sql para actualizaciones de bases de datos se incluirían en una transacción, por lo que podrían revertirse si algo sale mal.
- ¿Podría la respuesta proporcionar una pista de dónde podría buscar en el código para encontrar la respuesta a esta pregunta?

¡Gracias por tu tiempo!

¿Es esto cierto? Pensé que las declaraciones sql para las actualizaciones de la base de datos se incluirían en una transacción, por lo que podrían revertirse si algo sale mal.

Sus instintos de ingeniería son sólidos, pero lo que sucede en el mundo real de la programación de inicio de negocios es más complicado / feo.

El sistema de recursos de configuración de Magento no incluye scripts individuales en una transacción. Hay muchas razones para esto, pero siempre he asumido que la principal es que Magento comenzó su vida vinculada explícitamente a MySQL, y muchas / la mayoría de las declaraciones de definición de datos ( ALTER TABLE, etc.) en MySQL causan una confirmación implícita .

Si bien encontrará recursos de configuración individuales, a veces utiliza transacciones.

#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
    //...    

el sistema en sí solo ejecuta los scripts y espera lo mejor.

Si está interesado en el código que ejecuta estos recursos, el mejor lugar para comenzar es probablemente aquí

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

El _modifyResourceDbmétodo es el que incluye los scripts de recursos de configuración reales

#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;

Una solución muy hacky para su problema sería una anulación temporal de hack core / code-pool que se cerró explícitamente después de 5-10 incluye y vuelva a ejecutar eso. Esto reduciría la posibilidad de que un script de recursos de configuración se resbale a la mitad.

Una mejor solución, y uno de mis proyectos personales de "tal vez algún día" sería un script personalizado que utilizara los métodos principales de Magento para examinar las actualizaciones que deben aplicarse, enumerarlas y permitir a los usuarios ejecutarlas una por una.