L'aggiornamento del database Magento avviene in una "transazione"?

Abbiamo questo problema atm:

Un cliente ottiene il suo negozio aggiornato da CE 1.4 a CE 1.8. L'aggiornamento dei file è andato bene e anche l'aggiornamento del database è andato bene sulla nostra macchina di sviluppo.

Quando proviamo ad aggiornare il live-db del client sul suo live-machine (collega 1.8-Magento al database e lo apriamo nel browser), il processo sembra funzionare per un po 'e termina con un errore 500.

Il registro errori PHP è vuoto; poiché è un host condiviso, non possiamo modificare le impostazioni di apache o mysql; l'hoster, sebbene "specializzato in hosting magento", non è disposto a cambiare le impostazioni e mi dice che potrei finire l'aggiornamento del database aggiornando ripetutamente la finestra del browser quando si verifica l'errore 500, perché magento verrà quindi aggiornato a piccoli passi . Questo potrebbe andare avanti per ore.

La mia domanda ora è:
- È vero? Ho pensato che le istruzioni sql per gli aggiornamenti del database sarebbero state racchiuse in una transazione, quindi potrebbero essere ripristinate se qualcosa andasse storto.
- La risposta potrebbe fornire un suggerimento su dove potrei cercare nel codice per trovare la risposta a questa domanda?

Grazie per il tuo tempo!

È vero? Ho pensato che le istruzioni sql per gli aggiornamenti del database sarebbero state racchiuse in una transazione, quindi potrebbero essere ripristinate se qualcosa andasse storto.

Il tuo istinto ingegneristico è solido, ma ciò che accade nel mondo reale della programmazione delle start-up aziendali è più complicato / brutto.

Il sistema di risorse di installazione di Magento non include singoli script in una transazione. Ci sono molte ragioni per questo, ma ho sempre pensato che Magento abbia iniziato la sua vita in modo esplicito legato esplicitamente a MySQL, e molte / la maggior parte delle dichiarazioni di definizione dei dati ( ALTER TABLE, ecc.) In MySQL causano un impegno implicito .

Mentre troverai singole risorse di installazione a volte utilizzare le transazioni.

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

il sistema stesso esegue gli script e spera per il meglio.

Se sei interessato al codice che esegue queste risorse, il posto migliore per iniziare è probabilmente qui

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

Il _modifyResourceDbmetodo è quello che include gli script delle risorse di installazione effettivi

#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 soluzione molto confusa al tuo problema sarebbe un core-hack temporaneo / code-pool-override che è uscito esplicitamente dopo 5-10 include e rieseguirlo. Ciò ridurrebbe la possibilità che uno script di risorse di installazione esegua il salvataggio a metà.

Una soluzione migliore e uno dei miei progetti personali "forse un giorno" sarebbe uno script personalizzato che utilizzava i metodi di base di Magento per esaminare gli aggiornamenti che devono essere applicati, elencarli e consentire agli utenti di eseguirli uno per uno.