Nâng cấp cơ sở dữ liệu Magento có xảy ra trong một giao dịch trực tuyến không?

Chúng tôi có vấn đề này atm:

Một khách hàng được cửa hàng của mình nâng cấp từ CE 1.4 lên CE 1.8. Việc nâng cấp tệp đã diễn ra tốt đẹp và việc nâng cấp cơ sở dữ liệu cũng diễn ra tốt trên máy phát triển của chúng tôi.

Khi chúng tôi cố gắng nâng cấp db trực tiếp của máy khách trên máy trực tiếp của mình (kết nối 1.8-Magento với cơ sở dữ liệu và mở nó trong trình duyệt), quá trình này dường như chạy trong một thời gian và kết thúc với lỗi 500.

Nhật ký lỗi PHP trống; vì đây là máy chủ được chia sẻ, chúng tôi không thể thay đổi cài đặt apache hoặc mysql; hoster, mặc dù "lưu trữ im magento chuyên dụng", không sẵn sàng thay đổi cài đặt và nói với tôi rằng tôi có thể hoàn thành nâng cấp cơ sở dữ liệu bằng cách liên tục làm mới cửa sổ trình duyệt khi xảy ra lỗi 500, vì sau đó magento sẽ được nâng cấp theo các bước nhỏ . Điều này có thể diễn ra trong nhiều giờ.

Câu hỏi của tôi bây giờ là:
- Điều này có đúng không? Tôi nghĩ rằng các báo cáo sql cho nâng cấp cơ sở dữ liệu sẽ được gói trong một giao dịch, vì vậy chúng có thể được khôi phục nếu có bất cứ điều gì sai.
- Câu trả lời có thể cung cấp một gợi ý mà tôi có thể tìm trong mã để tìm câu trả lời cho câu hỏi này không?

Cảm ơn vì đã dành thời gian cho tôi!

Điều này có đúng không? Tôi nghĩ rằng các báo cáo sql cho nâng cấp cơ sở dữ liệu sẽ được gói trong một giao dịch, vì vậy chúng có thể được khôi phục nếu có bất cứ điều gì sai.

Bản năng kỹ thuật của bạn là âm thanh, nhưng những gì xảy ra trong thế giới thực của lập trình khởi nghiệp kinh doanh thì phức tạp / xấu xí hơn.

Hệ thống tài nguyên thiết lập của Magento không bao bọc các tập lệnh riêng lẻ trong một giao dịch. Có rất nhiều lý do cho việc này, nhưng tôi luôn cho rằng nguyên nhân chính là Magento bắt đầu cuộc sống gắn liền với MySQL và nhiều / hầu hết các câu lệnh định nghĩa dữ liệu ( ALTER TABLE, v.v.) trong MySQL gây ra một cam kết ngầm .

Trong khi bạn sẽ tìm thấy tài nguyên thiết lập riêng lẻ đôi khi sử dụng các giao dịch.

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

bản thân hệ thống chỉ chạy các kịch bản và hy vọng điều tốt nhất.

Nếu bạn quan tâm đến mã chạy các tài nguyên này, nơi tốt nhất để bắt đầu có lẽ là ở đây

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

Các _modifyResourceDbphương pháp là một trong đó bao gồm các kịch bản tài nguyên thiết lập thực tế

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

Một giải pháp rất khó giải quyết cho vấn đề của bạn sẽ là ghi đè tạm thời lõi-hack / mã-pool-pool đã thoát ra sau 5-10 bao gồm và chạy lại nó. Điều này sẽ làm giảm cơ hội của một tập lệnh tài nguyên thiết lập được bảo vệ một nửa.

Một giải pháp tốt hơn và một trong những dự án "có thể một ngày" cá nhân của tôi sẽ là một tập lệnh tùy chỉnh sử dụng các phương pháp cốt lõi của Magento để kiểm tra các bản cập nhật cần áp dụng, liệt kê chúng và cho phép người dùng chạy từng cái một.