Коллеги, доброго дня!
Столкнулся с таким:
Когда забираю доработки для основной конфигурации то возможности Вернуться к конфигурации базы данных нет (скрин),  
а если делать для расширения то возможность такая есть (скрин2). Почему так?

Потому что в первом варианте ты уже обновил конфигурацию БД, а во втором - нет.

(1) как будто вопросы с собеседования. Причем с не очень адекватного )

(2) Весна....

(0) Надмозги 1С так решили, что если конфа подключена к храну то возращаться к конфигурации БД не православно. Других проблем не вижу.

(4) так и есть
Да и возвращаться некуда, так как хранилище в общем случае = конфа в ИБ. Просто отменяешь изменения по захваченным ранее объектам

(5)

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

(6) потому что при подсоединении к хранилищу конфа в ИБ полностью заменяется на ту что в хранилище и отсюда стоит полагать, что если и вощвращаться куда-то то к конфе в хранилище
Понятное дело что в самой ИБ конфигкрация никуда не девается, но она есть копия хранилиша
При отсоединении от хранилища база становится самостоятельной и хоть заменяйся навозвращайся к конфе ИБ

(0) А к какой конфе ИБ ты собрался возвращаться?
Которая в хране? Так ты к ней уже "вернулся" при обновлении из храна

Которая в твоей базе?
Так нельзя, конфа же к храну подключена

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

(8) Практически желание очень даже обьяснимо. Притянули из храна документ, в этот момент выяснилось что он криво доработан, накатывать на прод в данный момент НЕ НАДО. (Реструктуризацию еще сделать не успели) Казалось бы откати до конфигурации БД и работай спокойно (как в конфе без храна), позднее притянешь исправленную версию. Но у надмозгов 1С другое мнение.

(9) А не надо прод напрямую к общему храну подключать

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

Или иметь свой совершенно отдельный хран только для прода (кроме базы прода туда никто не подключен)
И обновляться (в режиме сравнения и объединения понятно) через cf выгруженные из других хранов, например препрод или дев
Тогда откат будет откат в хране, и вся история есть что с продом делали

(7)>потому что при подсоединении к хранилищу конфа в ИБ полностью заменяется на ту что в хранилище и отсюда стоит полагать, что если и вощвращаться куда-то то к конфе в хранилище

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

Поэтому сама по себе связь с хранилищем не мешает вернуть основную конфигурацию к состоянию конфигурации БД. Тут скорее проблема в другом: при таком возврате платформа просто перетирает все целиком, не разбираясь, какие объекты нужно менять, а какие нет. А если конфигурация подключена к хранилищу, там часть объектов может быть не захвачена — и это приведет к проблемам. Мне кажется 1сникам просто лом допиливать этот механизм.

(10)Здесь не стоит вопрос, надо ее подключать к основному хранилищу или не надо. Вопрос стоит, почему вернуться нельзя если подключена. Само ограничение выглядит искусственным. А к какому она хранилищу подключена к основному, тестовому, общему или еще какому-то, вопрос десятый.

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

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

(13) Для другого разработчика все прозрачно. Он видит захваченный вами объект. Он понимает, что его пилят. Когда вы сдаете объект, то это не означает, что он мгновенно у всех в их базах появится. Только лишь когда подтянут изменения. И это нормально. Часто конфигуратор сам заставляет подтянуть некоторые сданные объекты, если они не подтянуты, но взаимосвящаны с тем, что вы пытаетесь захватить. Ладно пофиг на другого разраба.
Лично у вас после возврата к ИБ, если бы это было возможным, складывалось бы ложное мнение, что ваша конфа в ИБ = той что в хранилище. Рассинхрон. Да и по логике вещей, если подтянуть потом все изменения из хранилища, то все у вас неожиданно затрется, что ему не соответствует.

(14)

Возможно в вашей голове, может сложиться, ощущение что вы знаете какой объект в хранилище, находится в текущий момент. Но если вас в хранилище больше чем один разработчик, то думать так не надо никогда. Потому, что объект там может быть изменен кем угодно, в какой угодно момент пока он не захвачен вами. В этом суть хранилища.
Поэтому если рассинхрон и произойдет только с вашими ожиданиями. Логика работы с хранилищем никак не ломается от этого.


Все верно, прежде чем приступать к разработке, нужно получить актуальную версию объекта. Как она туда попала вопрос номер два. Почему это может быть для кого-то неожиданно, мне непонятно.

Потому, что ты когда, что-то положил туда, потом вернул, потом забыл, что вернул, потом, еще что-то с тобой произошло и вот ты уже не понимаешь. Где какой объект и что с этим делать.

Если речь идет об таком стиле работы, лучше не лезть в прод. Возможно не стоит иметь к нему доступ вообще, при таком уровне сфокусированности. Ответственность за то какой объект находится в базе и какой в хранилище, лежит целиком на разработчике при этом неважно может ли он откатить объект к данным БД или нет.

(1) нет, в первом случае у меня горит <!> и конфигурация БД еще не обновлена.

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