Решение для массовых акций Magento и проблемы с большим количеством записей?

Question

В настоящее время у Magento есть проблема с тем, как он обрабатывает массовые действия.Он возвращает бит JS, который содержит КАЖДЫЙ идентификатор базы данных для текущей коллекции и фильтра, независимо от нумерации страниц.Это делается для поддержки опции «Выбрать все» и «Выбрать все видимые» в заголовке сетки.Это не такая проблема, когда у вас меньше записей, но если у вас 850 тыс. Записей (в данном случае заказов), это становится серьезной проблемой.

Мой вопрос: есть ли у кого-нибудь элегантное решение?к этой проблеме?

Я могу подумать о нескольких решениях, каждое из которых имеет свои недостатки, но я надеюсь, что кто-то решил это простым способом, который работает как дополнительный модуль.Как платные, так и открытые решения приветствуются.

Пояснение:

Я ищу элегантное / выпадающее решение проблемы с записями 850k + с использованием виджета сетки в Magento.Стандартный Magento-код принимает необдуманное решение возвратить идентификатор для каждой записи, которая соответствует текущему фильтру, даже если они не отображаются.Речь идет не об автономной обработке записей, а об использовании виджета сетки для ежедневных задач администратора.

Одним из возможных решений было бы сохранить результаты отфильтрованного поиска во временной таблице и вернуть ссылку на результат поиска.Затем вы можете изменить его с использования фактических идентификаторов в «Выбрать все» на использование определенного обратного вызова для действия с использованием ссылки.Это сохранит текущее поведение.

Итак, еще раз спросите, есть ли у кого-нибудь хорошее решение для этого уже созданного?

Answer 1

Я выполняю тяжелые операции из сценария оболочки.У меня есть общий итератор (в моем случае продукты, но это можно сделать со всем остальным), и я реализую только класс, который выполняет действие над продуктом.Мой сценарий оболочки product_iterator заботится о том, чтобы зацикливаться на продуктах, одновременно обрабатывая только x продуктов (чтобы избежать утечек памяти).

Answer 2

Что ж, наименее инвазивное решение проблемы - отключить опцию «Выбрать все» для сеток с большим количеством записей. Это легко сделать, расширив класс grid и добавив следующий код:

protected function _prepareMassaction()
{
    $this->getMassactionBlock()->setUseSelectAll(false);
    return parent::_prepareMassaction();
}

Answer 3

Недавно я написал статью «Добавление нового массового действия в админ-сетку в Magento»,Надеюсь, вам понравится:http://www.blog.magepsycho.com/adding-new-mass-action-to-admin-grid-in-magento/

Описывает два способа добавления Mass Action1> Расширение Grid Layouts _prepareMassaction () метод2> Использование события: core_block_abstract_prepare_layout_before (более надежный способ обновления)

С уважением

Answer 4

Я думаю, что у fbmc правильный подход.Ясно, что даже если бы вы нашли способ отослать все записи по 850 тыс., У фреймворка случился бы сердечный приступ, пытавшийся справиться со всеми ними.Запустите логику в сценарии оболочки, если это то, что вам нужно.Для некоторых заданий вам может даже потребоваться запустить их в пакетном режиме или перейти к реальной логике SQL.

К сожалению, некоторые части инфраструктуры не были созданы для обработки такого масштаба.Вы нашли один из них.

Надеюсь, это поможет!

Спасибо, Джо