Нет таких версий платформы

8 3.8 один релизов например

А, ты про баги типа.
Но кажется что такой баг вряд ли надолго задержится в проде, т.е. платформа из-за него будет неукоснительно обновлена.

Это ты уже ко второй роли переходишь - выборке (обработке) этих изменений.
На этом этапе просто уже не нужно пользоваться платформенными методами :)
Для целей регистрации планы обмена - хорошая вещь. Я бы к доводам их не использовать отнес бы разве что невозможность в ЖР логировать (видеть) манипуляции с регистрацией на узлах, ну и отсутствие возможности хранить какую-нибудь доп. инфо об изменениях (например, штамп времени). Если есть такие требования то уже точно нужно городить свой регистр (механизм регистрации).

> На этом этапе просто уже не нужно пользоваться платформенными методами :)

ахах

не, ну если не выбирать из них, то да, хороший механизм :D

Выбирать. Но не платформенным методом, а только запросом. Никакого проигрыша тогда не будет по сравнению со сторонней реализацией.

а на таблицу изменений вешать управляемую блокировку?

(никогда так не делал, интересен кейс)

Предпочитаю делать это только на время проставления номера сообщения. А не на всю транзакцию выгрузки, как это в букварях и типовых на ОФ.
А после выгрузки - повторное считывание (в транзакции с блокировкой) номера сообщения, сравнение что за все время выгрузки (которое может быть большим) номер сообщения не изменился, и удаление (или оставление).
Альтернатива сравнению номера сообщения - это сравнение версии / хэша выгружаемого объекта (до и после выгрузки), но это уже не так универсально, т.к. несовместимо со сценарием когда я (или кто-то) хочет сбоку зарегистрировать изменение без модификации содержимого самого выгружаемого объекта - в этом случае моя регистрация может не обработаться (потеряться), если я совершу ее между двумя считываниями версии объекта.

Слишком круто для решаемой задачи

С отдельным РС под регистрацию изменений и всю обвязку - еще круче.
А тут уже все готовое, остается только сам метод забора изменений с узла и их надежной очистки реализовать и завернуть это все в РЗ.

Хотел бы ответить вашей гифкой где шварц жмет руку нигеру, но у меня ее нет

Сохраняй на будущее)

Скинь это куданить кодом плз. На досуге осознать.

Это способ регистрировать изменения и самому их отражать. Честно говоря сразу сомневался использовать план обмена только для регистрации изменений. Во-первых как всегда будут нюансы, во-вторых не уверен, что юзать лишь часть механизма для моей задачи нормально. Свою обвязку сделать для такой простой задачи интереснее и полезнее, как по мне .
Вопрос, стоит ли юзать такой способ, не лучше ли сразу регистрировать изменения при записи документа, и чем вообще руководстоваваться для принятия такого решения.

Я конечно хочу отражать информацию сразу при записи, и не пожалею времени, чтобы это выполнялось быстро. Но из-за того, что конфа уже огромная и не документированная, я не знаю какие могу вызыать последствия. В данном случае не нагружать запись докуметна важнее, чем актуальность информации. Вот я и призадумался.

Плюс я хотел в одном регистре собирать разные сведения. Сейчас понимаю, что это наверное не правильно и лучше будет разбить все на подзадачи.

Основная проблема в том, что на появление данных нужно отреагировать очень быстро, т.к. обработку этих данных ждёт другой сеанс
Порядка 10мс хотя бы, время на реакцию

Так и начните с синхронного режима, сколько времени занимает транзакция запись плюс сразу обработка?