ага все я понял как работает 3 вариант… Спасибо Вам огромное Николай за столь результативную беседу.
А где вы увидели много запросов к БД? И, вам уже выбирать какой вариант больше нравится.
а ничего что при последнем варианте будет так много обращений к БД? товаров может быть многооо
Вообще как вариант просто взять себе облачный сервер и настроить на нем мускул под свои нужды, включая увеличение длины строки для concat-функций. Но можно просто в цикле для всех магазинов наджоинить таблицу с формированием полей по маске, чтобы на выходе обработать полученные данные и набить в конечный запрос. А можно и вовсе составить запрос так, чтобы на каждый продукт получилось N-число записей, в каждой из которых будет ID магазина, кол-во и т.п. Типа так: select product_id, shop_id, count(*) as total from products p inner join shop_products sp on sp.product_id = p.id inner join shops s on sp.shop_id = s group by product_id, shop_id И полученные данные уже обрабатываете в цикле, набивая конечный массив, так же как у нас TV-шки набиваются.
( понятно что в никуда… сегодня магазинов 7 а завтра 27… и все приехали… а как можно заменить такую выборку? посоветуйте пожалуйста
А, ну да, у вас же там конкатинация. Значит гуглите смену длины для таких операций. Вот один из ответов. Выполняйте запрос SET SESSION group_concat_max_len = 100000; Но это путь в никуда ИМХО.
нету такой колонки вообще ни в одной таблице… это собирается с нескольких значений
А при чем тут это, когда 99% проблема в типе данных колонки data. Какой тип данных там указан и какая длина?
Еще раз перечитайте, что я писал: Как вариант: может у вас класс не по фэншую называется. Попробуйте закомментировать return 'StartupCreateProcessor'; и выполнить $modx->runProcessor() на него. Если название не соответствует принципу именований классов-процессоров MODX-а, то вы должны получить ошибку его вызова, потому как MODX не будет знать какой класс он вызывает. У вас: require_once MODX_CORE_PATH . 'components/startup/processors/mgr/create.class.php'; require_once MODX_CORE_PATH . 'components/startup/processors/mgr/update.class.php'; И далее вы делаете: public function saveProjekt($data = array()){ print_r($data); $response = $this->xpdo->runProcessor('mgr/create', $data,array('processors_path' => $this->xpdo->getOption('startup_core_path', null, $this->xpdo->getOption('core_path') . 'components/startup/') .'processors/'),$data); И в итоге что получаем? вы сам процессор в итоге вызываете в своем классе в методе saveProjekt()? А зачем? И дайте еще листинг вашего этого класса. Подозреваю, что именно там проблема. Проблема ваша в том, что вы намешали в кучу в один файл сразу несколько, по сути разрозненных, технологий. Вы расширяете класс modResource, но это следует делать только в тех случаях, когда вы пытаетесь получить свой CRC, то есть Custom Resource Class — расширенный класс ресурса. И судя по части методов в вашем классе это вы и пытались сделать. Но, если вы хотите использовать свои процессоры для обновления ваших документов, то документы ваши должны быть с вашим class_key. Тогда при вызове системного процессора resource/update будет вызываться ваш процессор на обновление документа, при условии что имя процессора соответствует маске. Вы же плюс ко всему пытаетесь еще вызвать принудительно процессор на обновление через $modx->runProcessor(). Класс процессора у вас уже подгружен, MODX не может опять его подгрузить ибо require_once и получается фигня.