уважаемые, поделитесь опытом, плз
допустим, у заказчика есть конфа на поддержке с возможностью редактирования, релиз платформы, допустим, старый, 8.2.13
я получил выгрузку базы, внёс некоторые изменения в конфу (добавил новые объекты, изменил некоторые существующие), выгрузил конфу в файл .cf, у меня релиз новый, 8.2.15 (совместимость не менял)

вопросы:
1. скажется ли каким-то боком различие в релизах при обновлении конфы на стороне заказчика?
2. как кошернее обновить конфу на стороне заказчика? я правильно понимаю, что через "Загрузить конфигурацию из файла", а не через "Сравнить, объединить", дабы не терять преемственность объектов?

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

(1) погодь, мне не надо обновлять конфу поставщика. а при Обновить она же обновится

(2) Ну тогда через сравнить-объеденить)

не знаю

(3) а почему не через Загрузить? уиды враздрыг разве не пойдут от этого? (в моей конфе, и конфе заказчика)

(1) Прежде чем советовать обновляться измененной конфигурацией через поддержку, стоит проверить, работает ли это, не?

открой твой подготовленный ЦФ-ник 8.2.13 релизом. То есть просто открой.. если что-то будет, то будет уже на этом этапе

кстати, попутный вопрос: при выгрузке основной конфы в cf в файле будет только она? конфы БД и поставщика там же не будут фигурировать?

(5) не пойдут, это обычно бывает при кривом обновлении методом ctrl с ctrl v из второго открытого конфигуратора.

(7) да я уже проделал на 8.2.13 (через Загрузить). просто, во-первых, не знаю точно, какой релиз на той стороне, только ветку (8.2.13), во-вторых, поверхностно посмотрел, в базу зашёл, изменения видны, но объёмно проверить нет времени. потому и спрашиваю, у кого какой опыт в данном вопросе

(9) тогда в чём отличие Загрузить и Объединить? только в окошке различий, а результат одинаков?

(9) просто в 7-ке с этим траблы были, потому и интересуюсь, как с этим в 8-ке

Объединить не обновит конфигурацию поставщика

(13) это я понимаю. ответь, плз, на (11)

(11) при Загрузить заменится все, при Объединить - то, что не мешает друг другу, объединится (отсутствующие ревизиты, документы, обработки).

(15) а, ну это понятно. т.е. за уиды и прочее я могу быть спокоен, и в будущем могу, после различных манипуляций с конфой на моей стороне, на стороне заказчика попеременно юзать то загрузку, то объединение, и ничего не "разъедется"?

2(16) давай придумаем серию экспериментов, которые должны подтвердить или опровергнуть что уиды метаданных могут разъехаться?

(16) например, если вы выгрузите cf без связанных справочников, то поля, использовавшие эти справочники, потеряют ссылки на них совсем.
При загрузке обратно - "приятно" удивитесь, сколько работы пропало впустую...

(14) конфа реально состоит из двух: основная и поставщика. При загрузить у тебя загрузится новая конфа поставщика.

(19) ага, т.е., если я правильно понял, то при Загрузить конфа поставщика также будет загружена из cf, а при Объединить - будет изменена только основная конфа, так?

(18) "выгрузите cf без связанных справочников"  это как?

(17) ну, например, такая модель:

1. я получил один раз выгрузку базы, и начал мучить в ней конфу.
добавил Док1, Модуль1, изменил некоторые объекты. больше конфу я у заказчика не беру, работаю с этой первоначальной, и из неё выгружаю cf
2. заказчик загрузил изменения через Объединить
3. я у себя изменил Док1, Модуль1, выслала заказчику новый cf
4. заказчик загрузил изменения через Загрузить

вопрос: у заказчика не пропадут введённые между пунктами 2 и 4 документы Док1?

^

(22) Да не загрузится она, не парься. Так же как и в семерке - не является прямым потомком, и все. Сообщение другое, суть та же.

Есть принципиальная разница между обновлением и объединением, при объединении не меняется релиз конфигурации поставщика, отчего неверно отрабатывает обработка ОбновлениеИБ(). А про загрузить вообще забудь, не будешь ты ей пользоваться с переписанной конфой, просто не даст.

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

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

+(27) Никаких изменений метаданных конечно. Если только модуль подправил, то может и загрузит со сносом этих изменений, по гуидам же смотрит. А так чтобы на место одного объекта другой засобачила, такого не будет.

(27) "Загружает пока в боевой базе никаких изменений не вносилось руками или объединением"  руками нет, а про объединение вот как раз и спрашиваю - например, ситуация (22)
и + смутило немного различие в платформах (у меня 8.2.15, у них 8.2.13), но, я так понимаю, явный косяк пойдёт только тогда, когда я уберу с конфы совместимость 8.2.13, правильно? а если совместимость оставить, то в каких ситуациях может возникнуть косяк?  например, на поставках конфигураций пишут: нужен релиз платформы не ниже 8.2.11, или 8.2.12, и т.п.

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

с тем же именем = с тем же идом конечно.

(31) ну, вот, собственно, это и хотел услышать. т.е. при объединении уиды новых объектов не создаются заново, а подтягиваются из cf, так?
и сравнение/объединение идёт не по имени объекта, а по уид?

(32) При загрузке не создаются, а подтягиваются. А так да... В общем как в семерке было, так и есть, логика не изменилась.

Сравнение/объединение по имени, загрузка по уид.

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

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

(36) А ты и не отрывайся... У тебя-то тоже на поддержке будет, просто из нее будешь делать свою поставку с тем же именем которая клиенту пойдет как одинэсовская, но с твоей уже правкой. Если что, можно будет и типовую вкатить. Единственное что отличий не увидишь сравнивая конфигурацию БД в боевой базе с конфигурацией поставщика, чтобы найти отличия придется с типовым cf'шником сравнить.

Что-то тут все запутали....
(22) вот что будет:
>1. я получил один раз выгрузку базы, и начал мучить в ней конфу.
добавил Док1, Модуль1, изменил некоторые объекты. больше конфу я у заказчика не беру, работаю с этой первоначальной, и из неё выгружаю cf

все УИД старой конфы - в вашей + УИД новых объектов - УИД тех объектов, кот. заказчик введет после выгрузки вам (вы их не получите до следующей выгрузки от него).

>2. заказчик загрузил изменения через Объединить

заказчик объединил две конфы с сохранением исходной + УИД новых объектов из второй объединяемой конфы.

>3. я у себя изменил Док1, Модуль1, выслала заказчику новый cf

вы ввели новые УИД (объекты) в свою выгрузку от заказчика

>4. заказчик загрузил изменения через Загрузить

зазказчик стер все изменения (2) и загрузил полностью вашу конфу (т.е. у него, как и у вас - конфа с объектами (1), (3) )

(21) а так: ваши доки привязаны к справочнику Номенклатура - но сам справочник вы не меняли, и потому, чтобы облегчить выгрузку, его не выгружаете (надеетесь, что потом при объединении конфа сама найдет "старые" УИД в полях).
Теперь вы объединяете выгрузку со своей (предположим, что объединение промежуточное, и у вас уже есть спр Номенклатура, но нет еще изменений промеж. выгрузки).
Так вот, в доках в полях, где была Номенклатура - будет пусто. Придется заново назначать тип данных поля.
Если и к заказчику потом выгрузите без связанных справочников - то и у него в ваших пришлых доках (а он объединением делает) не будет привязки к его спр Номенклатура.
Поэтому выгружать надо связанные справочники тоже. Это при условии, что эти справочники вы взяли изначально у него - если же попытаетесь натянуть "типа похожий", но не из конфы заказчика (спр Номенклатура из такой же типовой, но не Заказчика) - тут я не эксперементировал, но, похоже, УИДы в какой-то момент сменятся и такие справочники станут "разными".

А все остальное после (22) вы тут че-то непонятное обсуждаете :))

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

(38) "зазказчик стер все изменения (2) и загрузил полностью вашу конфу (т.е. у него, как и у вас - конфа с объектами (1), (3) )" - тут ощибочка - не загрузит. Не выйдет ничего.

(39) картина начинает складываться. т.е., как я и думал изначально, про объединение в данном случае нужно забыть.
и есть два варианта: Загрузка, или своя поставка, которые будут давать одинаковый результат, за исключениями:
1. в случае своей поставки конфа поставщика уже будет не типовая, а моя
2. в случае своей поставки можно не выгружать полностью конфу в файл для обновления клиента, а делать cfu-шки.

а так, результат (под результатом понимаю основную конфу, включая равенство всех уидов объектов между основной конфой моей и заказчика) будет одинаков. я всё правильно понял?

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

(41) cfu-шки можно, но гиморно, а так да. Будут все твои изменения в конфе поставщика и вся разница.

спасибо за разъяснения, вечерком ещё немного поэкспериментирую для закрепления результата.

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

В 1с все просто (это ж 1с - они там тожде ленятся делать что-либо сложное):
Объединить - пытается найти объекты по именам, и если находит - сравнивает, объединяет.
Загрузить - игнорирует одну конфу и полностью заменяет её новой.

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


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

(45) это мы, нверное, про данные?
тут-то как раз и не дает загрузить почему - данные по одной конфе ("старый" УИД1 у них), а загружается "другая" конфа (УИД2).
Вроде как меняется при изменении данных некий "текущий" УИД объектов - это чтобы не получилось так, что в объектах данные, а сами объекты - уже и не существуют...

+ т.е. я про "чистую" загрузку-выгрузку конфы (базы статичны), а если данные меняются у заказчика - то всегда только объединение (чтобы "догнать" временные текущие УИД базы заказчика).

(42) как и в (48) - если данные не менялись (УИДы не сменились) - загрузит.
А если менялись - то конечно не даст загрузить, смотри (48), почему.
Просто тут-то что обсуждаем? :))
Я обо всем, что после (22) написал в (46) и (48) :)

2(22) проверять будем?
И такой промежуточный ритуальный вопрос - как будешь проверять измелся ли УИД метаданных? По пропаже/не пропаже экземпляров этого метаданного в ИБ?
Не думаю что годный способ... Можно через ЗначениеВСтрокуВнутр()

(45) так работают только мудаки...

(45) Откройте для себя хранилище конфигурации и да будет счастье

>А ты и не отрывайся... У тебя-то тоже на поддержке будет, просто из нее будешь делать свою поставку с тем же именем которая клиенту пойдет как одинэсовская, но с твоей уже правкой. Если что, можно будет и типовую вкатить.

а вот не факт... своя поставка (имя поставщика) = свои id...