Порционная обработка данных очередями через рекурсивный вызов

[aiiddqd]

Где то читал что для работы плагина нужен сервер сайта помощнее, чтобы принять большой массив данных при первой синхронизации.

С чем связана эта проблема? С загрузкой самого файла на сайт? Или с обработкой этого файла уже на сайте?

Первый вариант мало верится.
Если второй вариант, то мы как то решали эту проблему, переписав функцию на рекурсивную обработку очередями. Вот некий пример http://wpcraft.ru/primer-massovoj-obrabotki-postov-v-wordpress-s-proslushkoj-cherez-hearbeat-api/

Как думаешь реально ли переписать механизм этого плагина на подобный?
Или могут быть какие то проблемы?

[sgtpep]

Дело в том, что все изменения (добавление, удаление, обновление данных) приходиться делать через методы API WordPress и WooCommerce, а не через прямые запросы к БД. Т.к. иначе не будет вызываться множество обработчиков и хуков, которыми обвешен код WordPress и WooCommerce.

Например, простое добавление категории делается через функцию wp_insert_term. Можно посмотреть, сколько кода и запросов зашито в её реализацию: https://core.trac.wordpress.org/browser/tags/4.4.2/src/wp-includes/taxonomy.php#L2547.

Ещё во многих окружениях веб-серверов стоит ограничение на время выполнения, поэтому плагин может не успеть импортировать большое количество данных. Т.е., в теории, продолжительность обмена прямо зависит от количества данных от 1С и обратно — от производительности сервера. Но даже на VPS за $5 у меня получалось импортировать десятки тысяч наименований, просто это занимало порядка 15 минут.

С загрузкой больших файлов же проблем, как правило, нет: он может передаваться частями и в zip-архиве.

Да, добавить пошаговый импорт было бы хорошо, чтобы не требовать от пользователей VPS или изменения max_execution_time. Но на момент начала разработки для меня это было большим усложнением. Например, в этом случае, скорее всего, понадобилось бы сохранять данные из 1С в промежуточные таблицы, т.к. единственный способ узнать, что на 1С удалились данные — сравнить новые данные с теми, что были импортированы в предыдущих обменах.

[aiiddqd]

Я сам против использования прямых SQL запросов. Но порционная обработка никак с этим не связана.

Я сомневаюсь что нужно сохранять данные в некие промежуточные таблицы.

Если говорить о механизме удаления старых продуктов, то можно придумать так:

1. Первым циклом пробегаться по CommerceML файлы и обновлять или добавлять все имеющиеся там продукты, помечая каждый обработанный продукт по ключу транзакции условно "i34234234". Если этот ключ стоит у продукта, это означает что продукт обновлен в последней транзакции.
2. Затем отбирать те продукты, у которых нет этого ключа. Это означает что данных о этих продуктах в последней транзакции не было. А значит они удалены из базы 1С. И их можно удалять с сайта.

Могу ошибаться в деталях, но как то так это должно работать с возможными корректировками.

Что же касается порционной обработки. То к примеру в системе МойСклад это легко реализуемо тк мы можем задавать отступ запроса данных, типа взять с 0 по 100 или с 100 по 200. И таким образом забирая только нужную порцию данных из МойСклад.

В случае с 1С как я понял на сайт попадает некий CommerceML файл, в котором изначально все данные уже есть. Таким образом нам нужно лишь попробовать брать из него не все данные за раз, а только с 0 по 100 записи. И далее с 100 по 200 и далее с 200 по 300. Вот как это сделать - это отдельный вопрос. Который я пока что не представляю, но думаю что если вникнуть в детали, то разберемся. И как только мы выясни как это сделать, то далее уже подойдет мой механизм который опубликова тут, с мелкими корректировками, и получим в результате порционную обработку с защитой от ошибок по таймауту.

[aiiddqd]

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

[vilninho]

Получилось у Вас сделать порционную выгрузку?

[aiiddqd]

С 1С так ничего и не вышло. Бюджета не хватило на проект.

Сейчас сосредоточились на МойСклад https://github.com/wpcraft-ru/wooms/

Там эту проблему решили так:

1. данные отдаются через REST API порциями
2. порция по 20-40 штук запускается раз в минуту и все это работает на минимальных хостингах без танцев с бубнами
3. сделан механизм сессий - по ним определяются продукты которые исчезли со Склада - они скрываются на Сайте.