Magento Veritabanı Yükseltmesi bir "işlem" içinde mi gerçekleşir?

Bu sorun atm var:

Bir müşteri mağazasını CE 1.4'ten CE 1.8'e yükseltti. Dosya yükseltme iyi gitti ve veritabanı yükseltme de geliştirme makinemizde iyi gitti.

İstemcinin live-db'sini canlı makinesinde yükseltmeye çalıştığımızda (1.8-Magento'yu veritabanına bağlayın ve tarayıcıda açın), işlem bir süre çalışıyor gibi görünüyor ve 500 hatasıyla bitiyor.

PHP hata günlüğü boş; paylaşılan bir ana makine olduğundan, apache veya mysql ayarlarını değiştiremeyiz; barındırıcı, "özel im magento hosting" olsa da, ayarları değiştirmek istemiyor ve bana 500 hata oluştuğunda tarayıcı penceresini tekrar tekrar yenileyerek veritabanı yükseltmeyi bitirebileceğimi söylüyor, çünkü magento daha sonra küçük adımlarla yükseltilecek . Bu saatlerce sürebilir.

Şimdi sorum şu:
- Bu doğru mu? Ben veritabanı yükseltmeleri için sql-ifadeleri bir işlem sarılmış olacağını düşündüm, bu yüzden bir şey ters giderse geri alınabilir.
- Cevap, bu sorunun cevabını bulmak için koda bakabileceğim bir ipucu verebilir mi?

Zaman ayırdığınız için teşekkürler!

Bu doğru mu? Ben veritabanı yükseltmeleri için sql-ifadeleri bir işlem sarılmış olacağını düşündüm, bu yüzden bir şey ters giderse geri alınabilir.

Mühendislik içgüdüleriniz sağlam, ancak iş kurma programlamasının gerçek dünyasında olanlar daha karmaşık / çirkin.

Magento'nın ayar kaynakları sistemi olmayan bir işlemde bireysel komut dosyalarını sarın. Bunun birçok nedeni var, ancak her zaman birincil olanın Magento'nun MySQL'e açıkça bağlı hayata başladığını ve MySQL'deki birçok / en çok veri tanımı ifadesinin ( ALTER TABLEvb.) Örtük bir taahhüde neden olduğunu varsaydım .

Bireysel kurulum kaynağını göreceksiniz, ancak bazen işlemleri kullanın.

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

sistemin kendisi sadece komut dosyalarını çalıştırır ve en iyisini umar.

Bu kaynakları çalıştıran kodla ilgileniyorsanız, başlamak için en iyi yer muhtemelen burada

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

_modifyResourceDbYöntem fiili kurulum kaynak kodları içerir biridir

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

Sorununuza çok hacky bir çözüm, 5-10 dahil sonra açıkça çıkılan geçici bir çekirdek hack / kod-havuz geçersiz kılma olacaktır ve bunu yeniden çalıştırın. Bu, bir kurulum kaynak betiğinin yarıya inme şansını azaltacaktır.

Daha iyi bir çözüm ve kişisel "belki bir gün" projelerimden biri, uygulanması gereken güncellemeleri incelemek, listelemek ve kullanıcıların bunları tek tek çalıştırmasına izin vermek için Magento çekirdek yöntemlerini kullanan özel bir komut dosyası olurdu.