Есть Розница 2.3.4 с пачкой расширений.
Я обновляю розницу до 2.3.6, вношу правки в расширения, далее делаю синхронизацию с узлом.
Иду в узел, делаю синхронизацию, вижу надпись о том, что получено обновление, и что его нужно установить.
Далее иду в конфигуратор узла, смотрю изменения и вижу, что конфигурация обновлена до 2.3.6 (но изменения не приняты), а вот изменения расширений в узел не прилетели.
На тестовом прогоне это привело к тому, что обновление конфы в узле встало, а вот запускаться база перестала, так как в расширении был тип, которого больше 2.3.6.
Это шутка такая от 1С?
Как правильно обновлять подобные базы?

Походу расширение нужно отдельно применять на каждой базе..
А что 1С где-то писала про поддержку расширений в РИБ?

А вообще с расширениями лучше не шутить :)

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

Тем более что обновления с расширениями становятся более увлекательные :)

(1) Если это РИБ и если это не РИБ - поведение расширения отличается.

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

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

(2) С расширениями вообще-то надо не шутить, а нормально работать. Вдумчиво.

И не обновления становятся увлекательнее, а дурость разработчика выпячивается наружу.

(0) Как правильно - не очень пока еще выяснилось. Но в самом расширение есть свойство для включения его в РИБ - данные от этого в РИБ не должны попасть, но Расширение через обменный файл будет передано. На кой хрен его туда передавать - идея, в принципе, логичная, но тупость тоже очевидна, т.к. структура передаваемых через РИБ данных не автоматическая, а настраивается в составе плана обмена и это далеко не все объекты метаданных, только некоторая особо ценная для работы часть, только часть, а не абсолютно все-все-все данные базы.

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

Думаю, что надо делать свой новый обмен, чтоб от багов и фичей платформенного РИБ не зависеть.

(0) Если ты пишешь, что "расширение не встало" - оно включено по свойствам в РИБ и оно меняет структуры типовых данных текущей базы, которые вставлены в РИБ?

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

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

(3) >Если расширение имеет внутри себя структуру метаданных
Что это значит? Если добавлены новые объекты метаданных? Есть один регистр, это оно?в
https://i.imgur.com/3P2zaij.png

>Структурно меняющееся расширение для поведения РИБ критично
А это что значит?) Речь про те же новые объекты метаданных?

>т.к. типовой РИБ тупой - он смотрит по хэш-функциям совпадение метаданных для данных
Если мы добавляем новый реквизит или расширяем какой-то типовой, хэш же должен поменять, разве нет?

(4) Конечно, все расширения имеют галку "Используется РИБ". Как иначе то, когда имеем 30+ узлов РИБ?

(5) Ну, для 2-3 узлов это, может, и имеет смысл, но дальше станет очень больно

(6) Обмен расширениями с РИБ - это механизм платформы или БСП?

(7) >оно меняет структуры типовых данных текущей базы
Что это значит? Не понимаю(

>А что типовые данные твое Расширение изменило?
Объясни плз, что имеется в виду

Во время теста я также снял галку активности у одного расширения - в нем в основном расширены типовые объекты, плюс добавлена обработка, и добавлено пару реквизитов в типовую обработку:
https://i.imgur.com/qN7NoNH.png
Так вот, после того как в узел выгрузились изменения конфы, галка активности у этого расширения осталось не тронутой, хотя ожидалось, что она снимется.

// галка активности у этого расширения осталось не тронутой, хотя ожидалось, что она снимется.

Активность самого расширения и не будет сниматься или включаться при обмене РИБ - это же вручную управляется. Более того, в результате обмена активность может слететь не потому, что ее кто-то отключил, а потому, что будут проблемы с его включением.

// Если добавлены новые объекты метаданных?

Любое изменение метаданных, если оно повлияет на расчет хэша по структуре данных

// Если мы добавляем новый реквизит или расширяем какой-то типовой

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

// Как иначе то, когда имеем 30+ узлов РИБ?

При таком числе узлов - это на любителя

Да, я могу на основе РИБ создать сам узел, но я не буду устраивать оперативный обмен данными на основе РИБ при таком количестве узлов.

// Обмен расширениями с РИБ - это механизм платформы или БСП?

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

(8)

///
>А что типовые данные твое Расширение изменило?
Объясни плз, что имеется в виду
///

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

Хочешь добавить новые данные? Добавляй. Но типовые данные при этом не ломай!