Поточний склад - 1 при запуску скриптів оновлення

Будь-яка ідея, чому Mage::app()->getStore()повертає вигляд магазину з id 1, коли всередині скриптів оновлення незалежно від представлення магазину я запускаю скрипт оновлення (навіть адміністратор)?
Я маю на увазі, я знаю, де код, який це робить. У Mage_Core_Model_App::getStore()цьому є:

    if (!Mage::isInstalled() || $this->getUpdateMode()) {
        return $this->_getDefaultStore();
    }

і _getDefaultStoreвиглядає так:

   if (empty($this->_store)) {
        $this->_store = Mage::getModel('core/store')
            ->setId(self::DISTRO_STORE_ID)
            ->setCode(self::DISTRO_STORE_CODE);
    }
    return $this->_store;

$this->_store завжди порожній при досягненні вищевказаного методу.

Я отримую той же результат, навіть якщо додати це у верхній частині сценарію оновлення:

Mage::app()->setCurrentStore(Mage::getModel('core/store')->load(Mage_Core_Model_App::ADMIN_STORE_ID));

Мені цікаво бізнес-логіка мати цю «особливість».

Примітка: не забувайте, що область зберігання адміністратора не встановлена, поки не відбудеться диспетчеризація і не Mage_Adminhtml_Controller_Actionвиконає контролер, який розширює (див. adminhtml_controller_action_predispatch_startПодію та пов’язаного з цим спостерігача Mage_Adminhtml_Controller_Action::preDispatch()).

Мені цікаво бізнес-логіка мати цю «особливість».

Ви не єдиний; з цього приводу ми можемо ніколи не дізнатися, якщо Моше чи Діма не захочуть обговорити.

Сценарії налаштування виконуються на початку ініціалізації програми. Проект цього, мабуть, пов'язаний з тим, що до моменту виконання решти стека необхідні міграції та інші роботи будуть "виконані" - це означає, що система була готова використовувати відразу ж під час встановлення модуля або оновлено. Мені цікаво, чи спочатку архітектори думали, що буде потреба у більш ініціалізованій системі. Я припускаю, що, хоча значна частина коду припускає, що наявний екземпляр магазину, _getDefaultStore()логіка гарантує наявність екземпляра магазину.

Повні параметри обсягу доступні в 1.4.0.0 і вище за допомогою сценаріїв налаштування даних.

Гаразд, для використання магазину адміністратора у ваших сценаріях оновлення просто використовуйте

Mage::app()->setCurrentStore(Mage_Core_Model_App::ADMIN_STORE_ID);

Ваш підхід Mage::app()->setCurrentStore(Mage::getModel('core/store')->load(Mage_Core_Model_App::ADMIN_STORE_ID)); не може досягти успіху, оскільки для адміністратора не існує дійсно існуючого перегляду магазину

Часто я використовую такий зразок:

// remembering old current store
$currentStore = Mage::app()->getCurrentStore();

// switching to admin store
Mage::app()->setCurrentStore(Mage_Core_Model_App::ADMIN_STORE_ID);

// switching back to old current store
Mage::app()->setCurrentStore($currentStore->getStoreId());

Інакше іноді після виконання сценарію оновлення відвідувачі будуть переадресовані на сторінку адміністратора, а не на фронтенд.

Оновлення:

Я неправильно тлумачив питання нижче, тож ось нова спроба пояснити ^^

Сценарії оновлення викликаються методом глибше в core ( Mage_Core_Model_Resource_Setup::_modifyResourceDb(...))

Тут я спробував перелічити стек

• Mage_Core_Model_App::run($params)

• Mage_Core_Model_App::_initModules()

• Mage_Core_Model_Resource_Setup::applyAllUpdates()

• Mage_Core_Model_Resource_Setup::applyUpdates()

• Mage_Core_Model_Resource_Setup::_upgradeResourceDb($oldVersion, $newVersion)

• Mage_Core_Model_Resource_Setup::_modifyResourceDb($actionType, $fromVersion, $toVersion)

а тепер подивіться на Mage_Core_model_App::run($params):

public function run($params)
{
    $options = isset($params['options']) ? $params['options'] : array();
    $this->baseInit($options);
    Mage::register('application_params', $params);

    if ($this->_cache->processRequest()) {
        $this->getResponse()->sendResponse();
    } else {
        $this->_initModules();
        $this->loadAreaPart(Mage_Core_Model_App_Area::AREA_GLOBAL, Mage_Core_Model_App_Area::PART_EVENTS);

        if ($this->_config->isLocalConfigLoaded()) {
            $scopeCode = isset($params['scope_code']) ? $params['scope_code'] : '';
            $scopeType = isset($params['scope_type']) ? $params['scope_type'] : 'store';
            $this->_initCurrentStore($scopeCode, $scopeType);
            $this->_initRequest();
            Mage_Core_Model_Resource_Setup::applyAllDataUpdates();
        }

        $this->getFrontController()->dispatch();
    }
    return $this;
}

метод _initModules()викликається до $scopeCodeі $scopeTypeвизначається.

В даний час я не можу зрозуміти, де визначено припущений запасний варіант.

Отже, основна відповідь полягає в тому, що він насправді потрапляє в третій, якщо ..... почекай що :(

if (!isset($id) || ''===$id || $id === true) {
    $id = $this->_currentStore;
}

Для мене це повертає true для Mage::isInstalled()і false, для $this->getUpdateMode()яких звучить неправильно. Але це відбувається лише при першому хіті getStore.

Отже, виявляється, що він налаштовує магазин до встановлення режиму оновлення, тоді, коли він повертається в сценарій настройки, він використовує виклик магазину за замовчуванням, який використовує наступний код:

$this->_store = Mage::getModel('core/store')
    ->setId(self::DISTRO_STORE_ID)
    ->setCode(self::DISTRO_STORE_CODE);

Значення self::DISTRO_STORE_IDдорівнює 1 Я думаю, тому що це щось потребує, і це не було налаштування для нас у адміністративному магазині :(

Тож у мене фактично є система, яка не зберігається з id 1, і сценарій оновлення, здається, працює добре. Якщо ми додаємо таблиці / атрибути, це нормально, і навіть при додаванні конкретного блоку cms для сайту це також працює, але ми отримуємо весь ідентифікатор магазину та спеціально встановлюємо їх під час збереження конкретних даних для зберігання.