Почему нельзя обновиться сразу до последнего релиза в пределах редакции? #764824

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

Или все-таки можно

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

Не пробовал, это так размышления

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

я бывает так делаю. Беру прежнюю типовую чистую (там данных нет и процедуры обновления быстрее) - накатываю все cfu - из результата беру cf и тестю на копии рабочего релиза.

При автоматическом обновлении нельзя обновиться сразу до последнего, не спроста же так придумали в компании 1С

касательно розницы, обновил с непоследней 1.0 до последней 2.1 в 2 скачка с сохранением данных.

Авторы типовых конфигураций утверждают, что в рамках одной редакции можно обновляться сразу. Но есть свидетельства пострадавших, что так работает не всегда. Выбор за вами. См. : копию, обновляют, тестируют результат и принимают решение. На файловой базе проблем быть не должно. Там действительно все обработчики обновления и конвертации данных будут выполняться последовательно. В клиент-серверной базе обработчики обновления делятся на два типа: - выполняемые в монопольном режиме (назовём их МО) - отложенные, выполняемые в разделенном режиме фоновым заданием уже после того, как отработают монопольные. таким образом (назовём их РО). Таким образом может возникнуть ситуация, когда при обновлении с версии 1.0 на версию 1.2  обработчики в файловой базе выполняться: Подобное изменения порядка обработчиков может оказаться критичным если в обновлениях и 1.1 и 1.2 менялись и обрабатывались одни и те же таблицы, но в разных обработчика - в монопольно выполняемых и в раздельно выполняемых.

Спасибо за развернутый ответ

А если в объекты конфигурации добавлены новые "свои" реквизиты, тогда есть вероятность потерять данные по ним с таким обновлением?

за технологию обновления из кому-то на селезневской надо в голову гвоздь забить

по-моему хороший пример: с этого года поменялся расчет зп (база НДФЛ, новые вычет и т.д.), эти данные заполняются обработкой обновления, но думается, в каком-то из релизов эту обработку уберут и при таком "прыжке" можно будет "промахнуться"

готовь cf с умом и ничего не пропадет базу, где ведется БУ (УПП 1.3) обычно обновляю перескоком, т.к. там очень редко что-то меняется

>> в каком-то из релизов эту обработку уберут С чего вдруг. Обработчики обновления никто не убирает. Их только добавляют. Если есть обработчик при обновлении на версию, например, 1.1, то он останется и в версии 1.99.

>базу, где ведется БУ (УПП 1.3) там этого угара и содомии из нету

+ вот если бы была та же БП 3.0, то так рисковать, т.к. постоянно вносят кучу изменений

>> надо в голову гвоздь забить Спорное мнение. Некоторые некритичные обработчики выполняются очень долго. Разделение обработчиков на монопольные и выполняемые раздельно значительно ускоряет процесс обновления больших баз данных. Хотя само по себе конечно решение неоднозначное.

+ нельзя обновлять если было удаление метаданных, пример: редакция 1 рекв А переименовали в удалить_а, при этом данные перенесли в новый регистр редакция 2 рекв удалить_А удалили при переходе сразй от редакции 0 к редакции 2 мы потеряем данные и регистр будет пустой

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

В типовых так никто не делает. Внутри одной редакции РеквА останется навсегда с префиксом "Удалить".

так ТС и пишет в топике, что в рамках одной редакции

при автоматической обработке конфигурации бух 2.0 работающей на платформе 3.0  - через интернет - автообработчик полез обновлять конфигурацию с 2.0 на 3.0 особо не спрашивая "с чегойто так надо" ... в результате от автоматических обработок отказались насовсем

в 90% случаях можно (когда понимаешь те варианты , когда это будет с проблемами). С проблемами - просто придется доп. самому вручную данные переносить ,из бекапа например. Один пример в Еще пример - проблема при  переименовании. Есть релиз 0 первоначальный. В релизе 1 обработка обновления работает с рекв111 (справочника или документа). В релизе 2 рекв111 переименован в рекв222 , обработка обновления в релизе 2 уже будет работать с рекв222 . Если мы сразу обновимся с релиза 0 на релиз 2 , то обработка обновления , которая должна была работать в релизе 1 выдаст ошибку , т.к. не найдет рекв111 . Соответсвенно все действия, связанные с этим реквизитом ,  придется отработать самому.

>Разделение обработчиков на монопольные и выполняемые раздельно значительно ускоряет процесс обновления больших баз данных. чтобы ускорить процесс пусть перерабатывают объектную модель -  запросы на update/insert/delete и т.п. от процесса обновления требуется одно - чтобы он был "однозначен" - либо он пройден ПОЛНОСТЬЮ и ПОСЛЕДОВАТЕЛЬНО либо нет...

>> от процесса обновления требуется одно - чтобы он был "однозначен" Нуууу.... В теории он однозначен. Разработчики типовых обещают, что всё должно быть тип-топ. Если ты пишешь свои собственные обработчики обновления, то делай их всегда монопольными (если есть сомнения). Лично я писал и монопольные обработчики и для выполнения в разделенном режиме. Но мне проще - я работаю с конкретной базой и всегда четко знаю с какого конкретной релиза и на какой конкретный релиз я обновляюсь и последовательность у меня точно однозначная.