Czy aktualizacja bazy danych Magento ma miejsce w „transakcji”?

Mamy ten problem atm:

Klient otrzymuje aktualizację swojego sklepu z CE 1.4 na CE 1.8. Aktualizacja plików przebiegła dobrze, a aktualizacja bazy danych przebiegła również dobrze na naszym komputerze programistycznym.

Kiedy próbujemy zaktualizować bazę danych klienta na jego komputerze na żywo (podłącz 1.8-Magento do bazy danych i otwórz ją w przeglądarce), proces wydaje się działać przez chwilę i kończy się błędem 500.

Dziennik błędów PHP jest pusty; ponieważ jest to host współdzielony, nie możemy zmienić ustawień apache ani mysql; hoster, chociaż „special im magento hosting”, nie chce zmieniać ustawień i mówi mi, że mógłbym dokończyć aktualizację bazy danych poprzez wielokrotne odświeżanie okna przeglądarki po wystąpieniu błędu 500, ponieważ magento zostanie następnie zaktualizowany w małych krokach . To może trwać kilka godzin.

Moje pytanie brzmi:
- Czy to prawda? Myślałem, że instrukcje SQL dotyczące aktualizacji baz danych zostaną opakowane w transakcję, aby można je było wycofać, jeśli coś pójdzie nie tak.
- Czy odpowiedź może dać wskazówkę, w której części kodu mogę znaleźć odpowiedź na to pytanie?

Dziękuję za Twój czas!

Czy to prawda? Myślałem, że instrukcje SQL dotyczące aktualizacji baz danych zostaną opakowane w transakcję, aby można je było wycofać, jeśli coś pójdzie nie tak.

Twoje instynkty inżynieryjne są dobre, ale to, co dzieje się w prawdziwym świecie programowania startupów biznesowych, jest bardziej skomplikowane / brzydkie.

System zasobów instalacyjnych Magento nie zawija pojedynczych skryptów w transakcji. Powodów jest wiele, ale zawsze zakładałem, że głównym jest to, że Magento rozpoczęło życie związane bezpośrednio z MySQL, a wiele instrukcji / definicji danych ( ALTER TABLEitp.) W MySQL powoduje niejawne zatwierdzenie .

Podczas gdy znajdziesz indywidualny zasób konfiguracji czasami używaj transakcji.

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

sam system po prostu uruchamia skrypty i ma nadzieję na najlepsze.

Jeśli interesuje Cię kod, który uruchamia te zasoby, najlepsze miejsce na rozpoczęcie prawdopodobnie znajdziesz tutaj

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

_modifyResourceDbMetoda to taka, która zawiera aktualne skrypty zasobów setup

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

Bardzo hackerskim rozwiązaniem tego problemu byłoby tymczasowe włamanie do rdzenia / pula kodów, które jawnie zakończyło się po 5-10 włączeniach, i uruchom je ponownie. Ograniczyłoby to szansę na awarię skryptu konfiguracji w połowie.

Lepszym rozwiązaniem, a jednym z moich osobistych projektów „może pewnego dnia” byłby niestandardowy skrypt, który wykorzystywał podstawowe metody Magento do sprawdzania aktualizacji, które należy zastosować, ich listę i pozwalania użytkownikom na ich przeglądanie jeden po drugim.