Есть УТ 11.4, не сильно доработанная по сравнению с типовой, но доработки ещё будут. Решил вынести доработки в расширение и привести конфигурацию к типовой. Сделал это на тестовой базе, но возник вопрос. В доработках конфигурации были добавлены несколько новых реквизитов. Как обновить рабочие базы, (привести их к типовым) без потери данных?

Сериализовать данные, обновить инфобазу (с потерей данных), добавить через расширение прежнюю структуру данных, загрузить ранее выгруженные данные в инфобазу обратно

(1) А если подключить расширение к ещё не приведенной к типовой конфигурации, и после этого обновить конфигурацию соответствующим типовым релизом с заменой объектов из релиза? Так не получится?

реквизиты оставляй лучше в конфе

(2) Так имена реквизитов одинаковыми не сделаешь

(1) а ты суров

(5) а есть какие-то другие предложения?

(6) Добавленные реквизиты никак не мешают обновляться, главное, чтобы разрабы не придумали такое же название своему реквизиту и ваш, добавленный, не перезаписался.
Смысла выносить в расширение - нет.

(7) Это то я в принципе понимаю, но хотелось бы максимально приблизится к типовой. И ещё вопрос возникает. А если есть добавленные реквизиты формы, то будет потеря данных при выносе их в расширение?

(6) Добавленные в расширение реквизиты заполнить копированием, затем удалить собственные реквизиты из основной конфигурации, а добавленные в расширении - переименовать.

(8) Реквизиты формы не имеют сохраняемых данных. Если вопрос о сохраняемом в настройках - то тут не известно мне, произойдёт ли восстановление по имени.

(8) сначала ответьте на вопрос - какое отношение реквизиты формы имеют к данным и их потере?

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

(12) данный метод конечно хорош с точки зрения поддержки, но он усложняет вывод данных на экран (форма документа и форма списка), а также запрос получения данных.

(12) Патамушта - гладий, олух!

Если это реквизит справочника, и доступна монопольное обновление, то делать из реквизита регистр сведений - ну... можно и в текстовый файл их записывать тогда. Ну ладно, ладно - с текстовым файлом перебор. В другую БД - точно можно записывать. Коль уж хочется нестандартного... нет, не секса, а чтоб заменить, якобы, некем было. В этом ж треше никто не разберётся и углядят "критический недостаток" - и перепишут на реквизит справочника за много денег.

(14) ты дебил?

(13) они там все равно собираются заморочиться с установкой Расширения и перекрытием типовых способов размещаемыми в расширение

(15) Нет. Пара нужна? Сочувствую.

а зачем вообще свои реквизиты добавлять
вполне нормально можно использовать регистрсведений
ДополнительныеЗначения  и в него писать серилизированый json к примеру с нужными данными а но форме это все показывать

да и в печать тоже все это отлично выводится потом

(7) Буквально на днях было - обновлял конфигурацию в которой добавлено было несколько реквизитов в регистр сведений. После обновления с удивлением увидел что данный регистр встал под замок и моих реквизитов там нет. Долго думал, ибо такое у меня впервые было. В итоге оказалось что они переименовали старый РС в УдалитьРС и запилили новый с таким же названием

(19) вот-вот! При массовых допилах мало того, что приходится свои объекты в метаданных добавлять (не реквизиты, а целые объекты), но еще и префиксы для уникальности этим объектам давать, как в расширении и делается по умолчанию

(0) сделать в расширении реквизиты с "_" в конце.
Обработкой заполнить данные в реквизитах.
Удалить из конфигурации добавленные реквизиты.
Переименовать реквизиты в расширении (убрать "_")

(18) Наверное, затем, чтобы не изобретать трэш с сериализацией json, не усложнять работу программистов на ровном месте, не усложнять работу БД лишними соединениями в запросах и сериализацией, кстати, как она в запросах, хорошо работает?

(20) Я за постфиксы, особенно в синонимах )

(12) Дольше разработка, больше неудобств для разработчика по организации как отображения, так и взаимодействия с такими "подчиненными" данными (в отличие от реквизита, лежащего в объекте "напрямую"). Ну это если не требуется CLS мутить на новые реквизиты, иначе конечно же в объекте хранить не айс.

Хотя вон в СКД есть механизм характеристик и тогда такое отдельное хранение заходит на ура (чтоб через плюсик работало).
Но все равно приходится то тут, то там разработчику думать, когда данные хранятся не в самом объекте, и поэтому добавление реквизита конечно же так повсеместно популярно.

(24) Я согласен, я тоже примерно так и думал, но вспомнил, что внутри типовых все равно подобное часто встречается. Особенно, когда мы смотрим на последние версии типовых. Куча, куча, куча программных слоев, а начиная с процедуры ПриСозданииНаСервере начинается типовая свистопляска с данными, которые хранятся порой хз где

(12) редактированием конфигурации занимались до меня и в принципе все изменения, которых было не так и много строго документировались и в коде комментировались. Даже если изменялся кусок кода или одна строчка, то оригинал не удалялся, а комментировался. Но с тех пор и изменений накопилось и самое главное резко возросло количество баз на предприятии. Учитывая, что изменения ещё планируются, обновление рабочих баз стало трудоемким. Предыдущий программист либо не знал про расширения, либо сознательно их игнорировал. Реквизитов добавил не так много, но они есть в типовых объектах. Хорошо что хоть основной объем доработок сделал при помощи дополнительных объектов, ВПФ и внешних обработок. Так что каши особой нет, но все-же косячки некоторые мешают.

(26) >> Предыдущий программист либо не знал про расширения

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

(27) 8.3.6

(27) ... аааа ты про реквизиты.... не вчитался ))))

(29) Ага

(30) раз зашла такая тема, то у меня ещё вопрос. Можно ли Экспортные функции ОбщихМодулей выносить в расширение? Никогда просто с такой задачей не приходилось сталкиваться. А необходимость есть. Обнаружен один баг, про который 1С знает, но отвечает одно, проблема будет решена. При этом выходит релиз за релизом, решения нет и это длится в течении уже почти года.

(31) Я не против

(31) Можно, но умеешь функции перехватывать директивой "Вместо"?

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

Это лучше чем перекрывать всю типовую функцию.

(33) по ходу я так и перехватываю. не понял в чем тут-то сложность? Или надо по всей конфе пройтись, где этот ОбщийМодуль вызывается.

(33) Ты ничего не попутал?

(35) Пиши конкретнее, видишь же, что попутал! Завязывай с удочками - нам рыба нужна))

(35) >> Да видимо. Тут не "вместо", тут "после". Для функций.

(36) (37) Я ж не был уверен - вдруг он "Вместо" + "Продолжить вызов" + потом еще что-нибудь и по-хитрому как-нибудь применяет. Поэтому спросил без наездов )

(38) А оказалось - все примитивно))

(29) насчет Реквизитов и их подцепливания к объектам в Расширении. Тут же есть два, даже три основных способа, о них выше было упомянуто:
- прицепить реквизит ВНУТРИ объекта.
- прицепить к объекту ДопРеквизит или ДопСвойство типовыми способами
- прицепить свои регистры или справочники, подвязанные к нужному нам Объекту и запихать туда желаемые нами реквизиты.

Второй и Третий способы по сути одно и тоже, но или типовое или свое. В зависимости от древности типовой УТ, но в новых релизах ДопРеквизиты и ДопСвойства у большинства Объектов Справочников и Документов метаданных есть.

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

+

Я против.
Ибо После добавления реквизитов через расширения 1С удаляет элементы при ТиИ

Да, жопа какая-то

(43) Это ты об что? Надеюсь, не об погоду?

(42) надо бы на 8.3.14 прогнать

(45) на момент написания 8.3.14 была недоступно. А так как машина времени в ремонте, то прогонял на том что было

(44) Сообщение без ссылки-номера на другое сообщение - это либо ответ на предыдущее сообщение, либо подведение итога всей ветки или предыдущего локального в ней обсуждения. Я так думаю.