이것이 사실입니까? 데이터베이스 업그레이드에 대한 sql-statements가 트랜잭션으로 래핑되므로 문제가 발생하면 롤백 될 수 있다고 생각했습니다.
엔지니어링 본능은 건전하지만 실제 비즈니스 스타트 업 프로그래밍에서 발생하는 일은 더 복잡하고 추악합니다.
Magento의 설정 리소스 시스템 은 트랜잭션에서 개별 스크립트를 래핑 하지 않습니다 . 여기에는 많은 이유가 있지만, 항상 주된 것은 Magento가 명시 적으로 MySQL과 연계 된 삶을 시작한 것으로 가정했으며, MySQL의 많은 / 대부분의 데이터 정의 명령문 ( ALTER TABLE
등) 은 암시적인 커밋을 유발합니다 .
개별 설정 리소스는 때때로 트랜잭션을 사용합니다.
#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
//...
시스템 자체는 스크립트를 실행하고 최선을 다합니다.
이러한 리소스를 실행하는 코드에 관심이 있다면 시작하기 가장 좋은 곳은 아마도 여기입니다.
#File: app/code/core/Mage/Core/Model/Resource/Setup.php
protected function _modifyResourceDb($actionType, $fromVersion, $toVersion)
{
//...
}
이 _modifyResourceDb
방법은 실제 설정 리소스 스크립트를 포함하는 방법입니다
#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;
문제에 대한 매우 해킹 된 해결책은 5-10 포함 후 명시 적으로 종료 된 임시 코어 해킹 / 코드 풀 재정의입니다. 이렇게하면 설정 리소스 스크립트가 반쯤 통과 할 가능성이 줄어 듭니다.
더 나은 솔루션이자 개인 "아마도 하루"프로젝트 중 하나는 Magento 핵심 방법을 사용하여 적용해야 할 업데이트를 검사하고, 나열하고, 사용자가 하나씩 업데이트 할 수 있도록하는 사용자 지정 스크립트입니다.