Можно ли отменить захват объектов хранилища после обновления и как использовать это для очистки данных?

Работа с хранилищем конфигурации 1С — это ежедневная рутина для многих команд разработчиков. Однако, помимо стандартных функций версионирования и совместной разработки, механизмы хранилища скрывают в себе интересные нюансы поведения, которые можно использовать для решения нетривиальных задач. В этой статье мы подробно разберем вопрос отмены захвата объектов после наката обновления, а также рассмотрим, как этот механизм превращается в мощный инструмент для администрирования базы данных.

Суть проблемы и вопросы

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

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

Базовое поведение: Отмена захвата после изменений

Для начала ответим на прямой вопрос. Рассмотрим ситуацию по шагам:

1. Вы захватываете объекты в хранилище.
2. Вносите в них изменения (вручную или через «Сравнение и объединение» с файлом обновления).
3. Понимаете, что изменения ошибочны или не нужны.
4. Выбираете действие «Отменить захват».

Результат: Конфигурация вернется в состояние, которое зафиксировано в хранилище последней версией. Локальные изменения будут потеряны. Объекты, как метко замечено в обсуждении, «подгрузятся из хранилища, как будто изменений не было».

Однако здесь есть критически важный нюанс, касающийся структуры базы данных (SQL или файловой).

Если после обновления конфигурации (шаг 2) вы успели нажать F7 (Обновить конфигурацию базы данных), то структура таблиц в базе данных уже изменилась. Если после этого вы отмените захват (шаг 4), то конфигурация вернется к старому состоянию, но база данных останется в новом. При следующем нажатии F7 платформа потребует реструктуризации обратно — к старому состоянию. Если изменений в структуре данных (добавление полей, индексов) не было, это пройдет быстро. Если были — потребуется время.

Продвинутая техника: Очистка огромных регистров через Хранилище

Наибольший интерес в данной теме представляет метод быстрой очистки таблиц, предложенный участниками обсуждения. Представим, что у вас есть регистр сведений (или документ, или справочник) с миллионами записей. Вам нужно полностью очистить его.

Традиционный подход программиста выглядит так:

НаборЗаписей = РегистрыСведений.НашОгромныйРегистр.СоздатьНаборЗаписей();
НаборЗаписей.Записать(); // Записываем пустой набор без отборов

Почему это плохо для больших объемов?

При выполнении этого кода платформа 1С выполняет на уровне СУБД (например, MS SQL Server) команду DELETE. Это транзакционная операция. Каждая удаляемая строка записывается в журнал транзакций (Transaction Log). Если строк миллионы:

1. Журнал транзакций (файл .ldf) разрастается до гигантских размеров, занимая все дисковое пространство.
2. Операция длится часами или сутками.
3. Возникают блокировки таблицы, мешающие работе пользователей.
4. Высока вероятность ошибки Out of memory или таймаута.

Алгоритм очистки через Хранилище (метод DROP/CREATE)

Участники форума предлагают элегантное решение, использующее механику реструктуризации. Давайте разберем этот алгоритм пошагово. Этот метод эмулирует команду SQL TRUNCATE TABLE или пару DROP TABLE + CREATE TABLE, которые выполняются почти мгновенно.

Порядок действий:

1. Захват объекта. В конфигураторе подключенном к хранилищу, захватываем нужный регистр (или справочник/документ).
2. Удаление в конфигурации. Удаляем объект из дерева метаданных (нажимая Delete). В этот момент объект удален только в черновике конфигурации.
3. Обновление ИБ (F7) — Ключевой этап. Применяем изменения к базе данных. Платформа видит, что объекта больше нет, и посылает СУБД команду DROP TABLE. Таблица удаляется физически вместе со всеми данными. Это происходит мгновенно и почти не пишет данных в журнал транзакций (только факт удаления метаданных).
4. Отмена захвата. Возвращаемся к окну хранилища и нажимаем «Отменить захват» для удаленного объекта (или корня конфигурации, если объект уже не виден).
5. Восстановление объекта. Поскольку в Хранилище объект не был удален (мы не помещали изменения, а отменили захват), он снова появляется в дереве метаданных конфигурации. Его свойства, измерения и ресурсы — всё на месте.
6. Повторное обновление ИБ (F7). Применяем изменения. Платформа видит, что в конфигурации есть объект, а в базе данных таблицы для него нет. Она посылает СУБД команду CREATE TABLE. Создается новая, абсолютно чистая таблица.

Итог: Мы получили пустой регистр за 5-10 минут (время уходит только на реструктуризацию и принятие изменений), вместо 10 часов удаления записей.

Важность сохранения GUID и отличие от ручного пересоздания

В обсуждении возник справедливый вопрос: зачем использовать хранилище, если можно просто удалить объект и создать такой же новый вручную? Давайте проанализируем разницу.

Каждый объект метаданных в 1С (Справочник, Регистр, Реквизит) имеет уникальный внутренний идентификатор (GUID). Он хранится во внутренних файлах конфигурации и используется для связей внутри системы.

Если вы удалите объект и создадите новый с таким же именем:

• У нового объекта будет новый GUID.
• Все ссылки на этот объект в других местах конфигурации (в типах реквизитов, в критериях отбора, в подписках на события, в ролях RLS) станут "битыми" (<Объект не найден>).
• Вам придется вручную восстанавливать все эти связи.
• Если вы используете Git или 1C:EDT, система контроля версий воспримет это как удаление одного файла и создание другого, что разорвет историю изменений объекта.

Преимущество метода с хранилищем (или метода с CF, описанного ниже):

При отмене захвата объект восстанавливается из хранилища с тем же самым GUID. Для платформы это "тот же самый" объект. Все ссылки в коде, ролях и типах данных сохраняются корректно. История версий (если ведется параллельно в Git) не прерывается.

Альтернативный метод: Использование CF-файла

Если у вас нет развернутого хранилища конфигурации, но задачу быстрой очистки нужно решить, можно использовать аналогичный подход с выгрузкой конфигурации (Message 7).

Алгоритм действий без хранилища:

1. В Конфигураторе выгружаем текущую конфигурацию в файл (Конфигурация -> Сохранить конфигурацию в файл... -> backup.cf).
2. В дереве метаданных удаляем очищаемый регистр.
3. Обновляем конфигурацию базы данных (F7). Таблица с данными уничтожается.
4. Выполняем «Сравнение и объединение с конфигурацией из файла» и выбираем наш backup.cf.
5. В окне сравнения находим наш удаленный регистр. Важно проверить настройки объединения.
6. Критический момент: Нужно убедиться, что режим сопоставления объектов установлен по внутренним идентификаторам (обычно это так по умолчанию). Если галочка "Режим копирования объектов" будет стоять неправильно, может создаться дубль. Но при восстановлении из CF того же самого объекта GUID должен сохраниться.
7. Объединяем и снова обновляем конфигурацию базы данных (F7). Создается пустая таблица.

Технические ограничения и предостережения

Несмотря на эффективность метода DROP/CREATE, мы должны помнить об ограничениях, накладываемых платформой 1С на удаление объектов.

Вы не сможете применить обновление (пункт 3 в алгоритме), если на удаляемый объект есть жесткие ссылки, которые препятствуют реструктуризации. Например:

• Регистр сведений является ведущим для другого регистра.
• На регистр ссылается реквизит документа или справочника (хотя для регистров сведений это редкость, но для справочников — обычное дело).
• Регистр участвует в последовательностях документов.

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

Резюме

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

2. Очистка таблиц через удаление метаданных, обновление БД и последующее восстановление объекта (через хранилище или CF) — это мощный прием для администраторов и ведущих разработчиков. Он заменяет долгие часы работы DELETE на мгновенный DROP/CREATE, но требует внимательности и понимания того, как работают идентификаторы метаданных (GUID).