Я бы сказал, я ставлю задачу максимально сохранить замочек на типовых объектах конфигурации, само собой за исключением корня)

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

>  что обновление на лету это некий аналог динамического обновления.

я не ковырял точно, какие запросы выполняются на стороне субд при обновлении расширения, но из практики работы с нашей 24/7 системой могу поделиться опытом - там, где на двух-серверном кластере динамическое обновление бьет серверный (!!!) кэш в девяти случаях из десяти, обновление расширения еще ни разу его не ломало.

может быть я такой везучий. выборка конечно же не репрезентативна.

А при обновлении расширением пользователям нужно перезаходить в приложение?

Коллеги, добрый день. Хотелось бы услышать Ваш опыт на тему расширений или может быть подскажите, что почитать на эту тему.

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

Мнения с коллегами разделились.

На мой взгляд основная ценность расширений, это все таки менее болезненная доработка типовых механизмов конфигурации, для упрощения обновления в будущем. Если функционал абсолютно новый и не имеет отношения к типовой конфигурации, целесообразно вынести его за пределами расширения, т.е в виде подсистем в основную конфигурацию. Чего я опасаюсь? Что в один момент расширений будет слишком много и их будет гораздо сложнее администрировать, а так же есть опасения с точки зрения производительности или потенциальных проблем при работе с расширением, у меня до сих пор есть некие ассоциации, что обновление на лету это некий аналог динамического обновления. Ну и еще большим минусом вижу, что далеко не все возможности реализованы в расширениях на текущий момент времени, так и так часть функциональности будет лежать в виде подсистемы, а часть в виде расширения.

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

Система будет слабонагруженная, никакой нагрузки 24х7 не будет, в наличии будут огромные технологические окна для обслуживания.

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

После до в тж заметны дикие цифры в call/memory.
Как раз на размер цф, аккурат 2гб в ерп и все тупит. А если цф за 3гб, то после ДО работа в обновленной базе просто невозможна из-за жутчайших тормозов.
Допускаю, что с расширениями будет задействован похожий механизм, но в call/memory будет вычитываться не весь цф, а только расширение. Если они размером кб/мб - то никто ничего просто не чувствует.

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

Вон оно что. Могу это скопировать в тред на партнерке?

Я, собственно, это и имел ввиду )

Ссылку напиши потом

При чем это наблюдение было и на высоконагруженной базе (одна база на сервере). И на 20 чел, где 30 баз на сервере без нагрузки. Поведение аккурат после ДО и до перезапуска пользователей в базу.
Есть предположение, что раньше после ДО все ломалось, кэши и т.п. А несколько лет у меня ничего не ломается, но базы с большими цф после ДО жёстко тормозят без нагрузки на железо. Деоптимизация ДО в пользу надёжности?))

Что такое "до перезапуска пользователей в базу" - всех до последнего?

Что значит бьёт кэш?

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

а, ну т.е. стандартное поведение? ))))