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

12

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!

simonthesorcerer
la source
2
Peut-être pertinent: une nouvelle commande n98-magenrun qui vous permettra d'exécuter les scripts de migration un par un. github.com/netz98/n98-magerun/pull/274
Alan Storm

Réponses:

8

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.

Alan Storm
la source
Grande réponse et grande perspicacité, merci; aussi pour l'astuce comment résoudre mon problème. J'ai fini par mettre à niveau la base de données sur le serveur de développement et importer la base de données "prête" dans le nouveau système.
simonthesorcerer
2
FWIW, ce projet "peut-être un jour" est devenu le système: setup: commande incrémentale dans n98-magerun magerun.net
Alan Storm
Faites-moi savoir quand vous avez préparé ce script @AlanStorm;)
fkoessler