Две подписки на событие #597628

Вопрос простой: Есть две подписки на событие "Обработки проведения", в обоих есть один и тот же документ. В каком порядке они будут выполняться? Которая первая создана? В порядке в дереве конфигуратора? Заранее спасибо.

А поставить точки останова и проверить?

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

Уже обсуждалось. Не известно.

насколько помню, в документации написано, что порядок выполнения не определен

В произвольном порядке

От расположения звезд зависит.

Я бы не привязывался к порядку. Последовательность действий надо иначе контролировать

платформа  8.2.14.540. Тестирование показало, что порядок подписки = порядку в дереве конфигуратора. Не думаю что мне Боги были ко мне благосклонны, ибо проводил большой объем документов.

грамматика - не мой конек :)

см видимо за это время расположения звезд было постоянным

Привязаться к сортировке ... Не знаю.

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

Хм... Мне тоже казалось, что по порядку в конфигураторе... Особо порядок не важен, но за год не заметила другого.

В чем есть логика? В порядке создания объектов метаданных, от желания левого программиста отсортировать дерево метаданных, или, все таки в написании программ, не зависящих от сторонних факторов. Ксати и порядок создания объектов не определяет их результат запроса.

я бы проверил на порядок СОЗДАНИЯ подписчиков в дереве метаданных взять совершенно пустут конфу и 1. создать простейший документ 2. созать метод подписки на любое событие этого дока, назвав ПодпискаСоздана1(...). и сохранить конфу 3. созать метод подписки на это же событие этого дока, назвав ПодпискаСоздана2(...) и сохранить конфу и протестить меняя порядок уже в дереве и зная, что было создано первым, а что вторым. думаю именно время создания более логично

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

Тупо перемещая подписки на события в дереве конфы - меняется порядок запуска обработчиков.

никак не связаны. не стоит привязываться на порядок действия подписок на событие. про это говорилось в курсе Гилева

порядок будет произвольным. На этой неделе как раз курс смотрел, там это разбиралось

а вот накой две подписки?

на файловой проверял?

Ну чем тогда определяется порядок? Кто-нибудь может сказать не опираясь на "там же говорили" или "чувак в 10 сообщении наверно прав"? Механизм и логика какая-то должна быть!

нету логики ! 100% порядка следования таких подписок нет ! Переноси все в одну подписку

Состав объектов может быть разный.

+1000, наверное что б потом сложнее "чужому" в логике БД было разобраться -не показатель )

Почему? Например - общая на все документы и индивидуальныя на подсистемы - предлагаете условиями расписывать?

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

какие еще подсистемы? как проведение от них зависит?

У меня есть проверки и установка некоторых признаков. Какая разница? Так и мы не наблюдаем и все под контролем. Может действительно стоит слить подписки в одну и разнести логику по процедурам. Надо подумать.

А в чем польза от этого знания?