CS-Cart 4.14.1.SP1 RU (проблема была и на всех предыдущих версиях)
В интернет-магазине уже 95 тыс заказов. Таблица cscart_order_data весит - 9.3 ГиБ
Мы используем способы доставки СДЭК, OZON, Boxberry. И для каждого заказа, в таблицу cscart_order_data записываются все пункты выдачи этих способов доставки для выбранного города. Информация для одного заказа может весит по 5 Мб.
Без этой таблицы - мы не увидим информацию какой способ доставки и пункт выдачи был выбран клиентом.
Просиба сделайте так, чтобы в cscart_order_data записывалась информация только о выбранном пункте выдаче.
И есть ли способ очистить эту таблицу - при этом сохранив информацию о выбранном пункте и способе доставки?
1 лайк
Пишите если нужно в личку, есть готовое решение по очистки.
Вообщем рекорд на ~70к заказов база похудела с 13,5 гб до 2,9 гб.
Примерно на 1 заказ нормально иметь 50кб, то есть если у вас 1000 заказов, ваша таблица cscart_order_data должна весить примерно (не больше) 48,8 мб
У нас есть модуль Apiship, в нем под капотом уже 50 транспортных компаний и данная проблема была решена на моменте разработки. Так же он умеет работать с многоместными отправлениями, есть валидация заказ в транспортной компании и создание документов в админке сайта, а также и ещё много всего интересного.
Модуль размещён на нашем сайте и на маркетплейсе.
1 лайк
@ikoshkin а можно прокомментировать есть ли в этом какой то сакральный смысл или будет исправляться?
Могу предположить, что это сделано для редактирования заказов. Чтобы при правках был весь список доставок и не запрашивался ещё раз. Но, может быть, после закрытия заказа он уже не нужен и можно список автоматически удалять, экономя место в базе.
При редактировании заказа все запрашивается вновь, если не запрашивать, можно использовать устаревшие пвз.
1 лайк
С ходу не прокомментирую. Нужно изучать. Для всех баг-репортов (и в Help Desk, и на форуме) процесс изучения один:
-
Сотрудники поддержки воспроизводят проблему. При необходимости привлекают разработчиков на раннем этапе.
-
Когда баг подтвеждается, передают проблему в работу. Даже если проблема получает “Не признано багом”, то часто всё равно попадает в бэклог (но без обещания “исправим за 45 дней”).
-
По итогам исправления (или изучения) представитель компании отвечает на баг-трекере.
Эту проблему коллеги тоже изучат в порядке очереди.
2 лайка
Эта проблема на форуме гуляет с 2018 года, можно найти по поиску. Воспроизвести легко взять просто оформленный заказ на Москву со включенными модулями сдэк/бокс/пек/самовывоз и увидеть размер мусора.
3 лайка
Вынес всё обсуждение, не связанное с проблемой, в отдельную тему. А в этой теме ответим, как только доберёмся до этой проблемы.
1 лайк
Плюсую к теме и тоже жду решения от разработчиков! Уже второй год вынужден отключать бэкап при каждом обновлении, потому что сайт виснет на проклятой таблице cscart_order_data.
Однажды почистил ее запросом, который посоветовали тут на форуме. В итоге менеджер магазина материл меня еще полгода за то, что побилась куча заказов, появились в наличии старые товары и тд и тп. Больше таких хирургических вмешательств в базу делать не хочется
1 лайк
Было такое с новой почтой, в какой то момент отпустило. Это на уровне модуля доставки, там BLOB файл в который пишуться все отделения по городу(зачем-то) по идее достаточно писать туда только выбранный или не знаю зачем они там вообще нужны. Если большой город, то сразу запись о заказе раздувается. Я думаю нормальный разработчик смог бы быстро вам это поправить.
Прошло 23 дня. Разработчики смогли воспроизвести проблему?
Могу предоставить доступ к своей базе если это потребуется
Здравствуйте.
Приношу извинения за долгий ответ.
Я обратилась к разработчику по данному вопросу, и мы выяснили, что эта проблема не может быть исправлена без рефакторинга модулей доставки с автоматическим расчетом стоимости доставки.
Что касается проблемы с записью всех ПВЗ - есть шанс, что у модуля Магазины и пункты самовывоза это поведение возможно может быть исправлено относительно безболезненно.
Я создала задачу для изучения и сообщу, когда появятся какие-либо новости.
Спасибо
Здравствуйте.
При оформлении заказа, в базу данных сохранялись все доступные пункты выдачи заказа. Исправлено.
Исправление войдет в 4.15.3.
Для исправления проблемы собственными силами можно использовать патч: order_data.zip (1,4 КБ) Патч подходит для версий от 4.15.1 и выше.
О том, как применить патч, можно прочитать в нашей документации.
Перед применением патча рекомендуем сделать бекап БД.
Как должен работать патч:
В таблицу cscart_order_data записывается только ПВЗ выбранный покупателем.
Выбранный ПВЗ записывается только один раз, и не дублируется (ПВЗ магазина, ПВЗ способов доставки (СДЭК, Boxberry, Pickpoint))
2 лайка
Было бы хорошо сказать с какой версии можно патч применять, а то сейчас наставят на древние версии и стоит выпустить модуль который бы отчистил людям базы так как я сам видел как таблица из 3,6гб превращается в 500мб после выноса мусора оттуда
1 лайк
А как быть пользователям с версиями ниже 4.15.1? Таблица cscart_order_data так и будет продолжать заполняется ненужной информацией? 
Обновиться до последней версии, это вполне нормальное решение компании, если выпустить diff для всех начиная с 4.3.1 это дорогое удовольствие.
1 лайк