A atualização do banco de dados Magento acontece em uma "transação"?

Temos este problema em:

Um cliente recebe sua loja atualizada do CE 1.4 para o CE 1.8. A atualização do arquivo correu bem e a atualização do banco de dados também correu bem em nossa máquina de desenvolvimento.

Quando tentamos atualizar o live-db do cliente em sua máquina ao vivo (conecte o 1.8-Magento ao banco de dados e abri-lo no navegador), o processo parece durar um pouco e termina com um erro de 500.

O log de erros do PHP está vazio; como é um host compartilhado, não podemos alterar as configurações do apache ou do mysql; o hoster, apesar de "hospedagem especializada em magento", não está disposto a alterar as configurações e me diz que eu poderia concluir a atualização do banco de dados atualizando repetidamente a janela do navegador quando ocorrer o erro 500, porque o magento será atualizado em pequenas etapas . Isso pode durar horas.

Minha pergunta agora é:
- Isso é verdade? Eu pensei que as instruções sql para atualizações de banco de dados seriam agrupadas em uma transação, para que pudessem ser revertidas se algo der errado.
- A resposta poderia fornecer uma dica de onde eu poderia procurar no código para encontrar a resposta para esta pergunta?

Obrigado pelo seu tempo!

Isso é verdade? Eu pensei que as instruções sql para atualizações de banco de dados seriam agrupadas em uma transação, para que pudessem ser revertidas se algo der errado.

Seus instintos de engenharia são sólidos, mas o que acontece no mundo real da programação de inicialização de negócios é mais complicado / feio.

O sistema de recursos de instalação do Magento não envolve scripts individuais em uma transação. Há muitas razões para isso, mas sempre assumi que a principal é Magento iniciada vida explicitamente ao MySQL, e muitas / a maioria das declarações de definição de dados ( ALTER TABLEetc) no MySQL causam uma confirmação implícita .

Embora você encontre recursos de configuração individuais, às vezes use transações.

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

o próprio sistema apenas executa os scripts e espera o melhor.

Se você estiver interessado no código que executa esses recursos, provavelmente o melhor lugar para começar é aqui

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

O _modifyResourceDbmétodo é o que inclui os scripts de recursos de instalação reais

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

Uma solução muito hacky para o seu problema seria uma substituição temporária de core-hack / code-pool-pool que saiu explicitamente após a inclusão de 5 a 10 e a executou novamente. Isso reduziria a chance de um script de recurso de configuração ser liberado na metade.

Uma solução melhor e um dos meus projetos pessoais "talvez um dia" seria um script personalizado que usasse os métodos principais do Magento para examinar as atualizações que precisam ser aplicadas, listá-las e permitir que os usuários as executassem uma a uma.