La mise à niveau de la base de données Magento se produit-elle dans une «transaction»?

Nous avons ce problème atm:

Un client fait passer sa boutique de CE 1.4 à CE 1.8. La mise à niveau des fichiers s'est bien déroulée et la mise à niveau de la base de données s'est également bien déroulée sur notre machine de développement.

Lorsque nous essayons de mettre à niveau la base de données en direct du client sur sa machine en direct (connectez le 1.8-Magento à la base de données et ouvrez-le dans le navigateur), le processus semble fonctionner pendant un certain temps et se termine par une erreur 500.

Le journal des erreurs PHP est vide; comme c'est un hôte partagé, nous ne pouvons pas changer les paramètres apache ou mysql; l'hébergeur, bien que "hébergement spécialisé im magento", ne souhaite pas modifier les paramètres et me dit que je pourrais terminer la mise à niveau de la base de données en actualisant à plusieurs reprises la fenêtre du navigateur lorsque l'erreur 500 se produit, car magento sera ensuite mis à niveau par petites étapes . Cela pourrait durer des heures.

Ma question est maintenant:
- Est-ce vrai? Je pensais que les instructions sql pour les mises à niveau de base de données seraient enveloppées dans une transaction, afin qu'elles puissent être annulées en cas de problème.
- La réponse pourrait-elle fournir un indice où je pourrais regarder dans le code pour trouver la réponse à cette question?

Merci pour votre temps!

Est-ce vrai? Je pensais que les instructions sql pour les mises à niveau de base de données seraient enveloppées dans une transaction, afin qu'elles puissent être annulées en cas de problème.

Vos instincts d'ingénierie sont solides, mais ce qui se passe dans le monde réel de la programmation de démarrage d'entreprise est plus compliqué / laid.

Le système de ressources de configuration de Magento n'encapsule pas les scripts individuels dans une transaction. Il y a beaucoup de raisons à cela, mais j'ai toujours supposé que la principale est la vie commencée par Magento liée explicitement à MySQL, et la plupart / la plupart des instructions de définition de données ( ALTER TABLE, etc.) dans MySQL provoquent un commit implicite .

Bien que vous trouviez des ressources de configuration individuelles, vous utilisez parfois des transactions.

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

le système lui-même exécute simplement les scripts et espère le meilleur.

Si vous êtes intéressé par le code qui exécute ces ressources, le meilleur endroit pour commencer est probablement ici

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

La _modifyResourceDbméthode est celle qui inclut les scripts de ressources d'installation réels

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

Une solution très hacky à votre problème serait un remplacement temporaire du noyau / hachage de pool de code qui s'est explicitement arrêté après 5-10 inclus, puis réexécuté. Cela réduirait les chances qu'un script de ressources de configuration ne se vide à mi-chemin.

Une meilleure solution, et l'un de mes projets personnels "peut-être un jour" serait un script personnalisé qui utilise les méthodes de base de Magento pour examiner les mises à jour qui doivent être appliquées, les répertorier et laisser les utilisateurs les parcourir une par une.