Если у вас возникли какие либо вопросы которые вы не смогли решить по нашим публикациям самостоятельно,
то ждем ваше обращение в нашей службе тех поддержки.
Для начала надо получить ID товаров для передачи в фильтр компонента. Собственно, в этом и затык.
1. Можно дернуть через CSaleBasket::GetList последние товары с ненулевым ORDER_ID. Но как узнать дату заказа этих корзин? Дергать сначала заказы? А как узнать сколько заказов дернуть, чтобы набрать всего 10 товаров? В любом случае, два запроса, не айс.
2. Сортировать ненулевые корзины по дате вставки или дате обновления тоже не вариант. Действия с заказом апдейтит поле обновления, а дата вставки может быть очень старой. Не вариант.
3. Писать свой запрос с JOIN одной таблицы к другой? Пошел с этой стороны, но что-то как ни колдовал, на 500т. корзин и 150т. заказов время варьировалось до 0.6 секунд. Недопустимо для одного запроса.
4. Неужели придется при заказе инсертить товары в отдельный инфоблок? Не очень хочется избыточных данных.
5. Можно было и дальше колдовать с п.3, но что-то мне не понравилось. Решил я через доп.свойство инфоблока и обработчик на оформлении заказа. Заводим св-во тип число "LAST_ORDER_ID". И вешаем такой обработчик на завершение оформления в одношаговом компоненте:
Готово!
Осталось отсортировать сколько надо товаров по этому полю и вывести их. Это и будут "последние заказанные товары".
Причем тут масштабируемость? А код из п.3 летал на нулевой коробке, но на магазине с тысячами заказов и корзин, он встал. Всегда смотрите в будущее и проводите хотя бы минимальные тесты. Имейте сервер с нагрузочной средой под рукой.
Назад в раздел
Наверх
то ждем ваше обращение в нашей службе тех поддержки.
Думаем о масштабируемости или как вывести последние заказанные товары?
Казалось бы - простая задача - вывести список товаров.Для начала надо получить ID товаров для передачи в фильтр компонента. Собственно, в этом и затык.
1. Можно дернуть через CSaleBasket::GetList последние товары с ненулевым ORDER_ID. Но как узнать дату заказа этих корзин? Дергать сначала заказы? А как узнать сколько заказов дернуть, чтобы набрать всего 10 товаров? В любом случае, два запроса, не айс.
2. Сортировать ненулевые корзины по дате вставки или дате обновления тоже не вариант. Действия с заказом апдейтит поле обновления, а дата вставки может быть очень старой. Не вариант.
3. Писать свой запрос с JOIN одной таблицы к другой? Пошел с этой стороны, но что-то как ни колдовал, на 500т. корзин и 150т. заказов время варьировалось до 0.6 секунд. Недопустимо для одного запроса.
4. Неужели придется при заказе инсертить товары в отдельный инфоблок? Не очень хочется избыточных данных.
5. Можно было и дальше колдовать с п.3, но что-то мне не понравилось. Решил я через доп.свойство инфоблока и обработчик на оформлении заказа. Заводим св-во тип число "LAST_ORDER_ID". И вешаем такой обработчик на завершение оформления в одношаговом компоненте:
public static function OnSaleComponentOrderOneStepCompleteHandler($ID, $arOrder, $arParams) {
if ($ID>0 && CModule::IncludeModule('iblock')) {
$rsCart = CSaleBasket::GetList(array(), array('ORDER_ID' => $ID));
while ($arCart = $rsCart->Fetch()) {
if ($arCart['MODULE']=='catalog' && $arCart['PRODUCT_ID']>0) {
CIBlockElement::SetPropertyValueCode($arCart['PRODUCT_ID'], 'LAST_ORDER_ID', $ID);
}
}
}
} |
Осталось отсортировать сколько надо товаров по этому полю и вывести их. Это и будут "последние заказанные товары".
Причем тут масштабируемость? А код из п.3 летал на нулевой коробке, но на магазине с тысячами заказов и корзин, он встал. Всегда смотрите в будущее и проводите хотя бы минимальные тесты. Имейте сервер с нагрузочной средой под рукой.
Назад в раздел
Подписаться на новые материалы раздела:
Загрузка...
Наверх