Регистр вместо плана обмена #753037

Нужно выгружать данные(справочники и отдельно остатки, цены) на сайт. Выгрузка полностью своя, ну там формирование xml файла и т.д., ну т.е. не через правила обмена, односторонняя выгрузка. Собственно, что бы накапливать изменённые данные есть объект как "Планы Обмена". Ну, а может быть лучше использовать регистр сведений? Как то более прозрачнее что ли и места по идее должен меньше занимать. Посмотрел замером производительности, в регистр будет писаться быстрее. Чтение, если запросом - то одинаково. Проблема с удалением данных из регистра. Допустим начинаем выгружать, считали данные, выгрузили, очистили регистр. Но пока выгружали - произошли новые записи туда, плюс возможно изменилиь данные в уже существующих объектах. В итоге просто так взять и очистить регистр нельзя, даже если будем очищать с отбором по единственному измерению, то это тоже нельзя + время. Короче может кто сталкивался с таким замутом? Стоит оно того? Хочется как лучше, а через ПланОбмена и само пойдёт)

У акселотовцев спроси. Они как-то говорили что регистр в своей конфе использовали из за каких-то проблем.

Изобретение велокатов с квадратными колесами - древняя традиция программистов вообще и одинэснегов в частности

Как один из вариантов реализации: тебе нужна ал-я версия записи в регистре. Для этого подходит например GUID. Изменили объект - в регистре сделали запись с автоматически сфорированным ID. Выгрузили объекты в XML вместе с их ID. На принимающей стороне прочитали и по тем объектам по которым все прошло удачно отправили обратно список подтвержденных ID. На отправляющей стороне чистим записи с подтвержденными GUID-ами. Если за время обмена объект изменился еще раз то он уже будет в регистре с другим ID. Единственный гемор - регистрировать изменения регистров сведений. Тут будет конкретный лисапед :)

я в вас не сомневался. Даже глубокой ночью вы свои 5 копеек в такую тему из под подушки то достанете.

А не этим ли занимается стандартный механизм обмена?

Стандартный механизм не позволяет принять данные частями. Тоесть если не можешь принять хотя бы 1 объект то заворачивается весь пакет. В большинстве случаев это не нужно поскольку ошибку по непринятому объекту просто пишут в лог и он улетает из обмена, однако когда известно что объекты могут загружаться не с первого раза то нужно пообъектное подтверждение о доставке, чего схема с номеом принятого/номер отправленного сообщения обеспечить не может.

Можешь прописать ДатаЗаписи и Читать данные с последней даты, а удалять можешь в фоне порциями для уменьшения конфликта при ответе последней полученной даты.

А что бы не было проблем что при выгрузке на 1 секунду могут добавится еще объекты выгружать данные на секунду меньше последнего документа.

Все описанные тобой задачи и вопросы, за тебя успешно решает план обмена. Ты можешь решить это и через регистр, но тогда потратишь много времени на код, который не имеет непосредственного отношения к твоим бизнес-требованиям, а решает чисто инфраструктурные задачи. Да и замеры твои - фуфло. Потому, что 1с не предрставляет средств для замера записи в таблицы регистрации

Которые тут про невозможность порционной загрузки, - вы топик читали вообще? Обмен односторонний из 1с на сайт

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

это да, слона то я и не заметил

Да и замеры твои - фуфло. Потому, что 1с не предрставляет средств для замера записи в таблицы регистрации. "Замер производительности" и ЗарегистрироватьИзменения фуфло?

Какая религия запрещает вести лог при использовании ПО?

План обмена заточен под свой функционал, не думаю, что велосипед окажется производительнее.

Не мешайте велосипедостроению. А если серьёзно На хрена

"Не мешайте велосипедостроению" Это единственная стабильно развивающаяся отрасль в России