Что хранится в таблице ConfigCAS и как 1С работает с расширениями на уровне базы данных?

При администрировании баз данных 1С:Предприятие на уровне SQL-сервера разработчики часто замечают таблицы, названия которых отличаются от привычных объектов метаданных. Одной из таких таблиц является ConfigCAS. Особенно много вопросов возникает, когда количество расширений в базе не совпадает с количеством строк в этой таблице. Давайте подробно разберем, для чего нужна эта таблица, как расшифровывается её название и по какому принципу 1С организует хранение расширений конфигурации.

Назначение таблицы ConfigCAS и расшифровка названия

Для начала выясним, что скрывается за аббревиатурой. CAS чаще всего расшифровывается как Configuration Application Storage (хранилище прикладных конфигураций) или, в узком техническом смысле применительно к расширениям — Configuration Extension Storage. Рассмотрим ситуацию: начиная с версии платформы 8.3.6, появилась возможность использовать расширения, которые позволяют кастомизировать систему, не снимая основную конфигурацию с поддержки.

Для хранения этих расширений платформе потребовалось отдельное системное хранилище, изолированное от основной конфигурации. Если основная конфигурация «живет» в таблице Config, то все данные по расширениям вынесены в ConfigCAS. Это позволяет платформе быстро применять или отключать расширения при запуске сеанса без модификации структуры основной конфигурации.

Почему строк в таблице больше, чем самих расширений?

Проанализируем ситуацию, когда в базе подключено всего 3 расширения, а в таблице ConfigCAS мы видим несколько десятков строк (например, 36). Это не является ошибкой или избыточностью. Разберем по шагам, почему так происходит:

1. Декомпозиция объектов: 1С не хранит всё расширение целиком в одной бинарной записи. Каждое расширение разбивается на логические блоки. В таблице создаются отдельные записи для метаданных, для форм, для модулей и для справочной информации. Каждая такая часть имеет свой уникальный идентификатор в колонке FileName.
2. Служебные индексы: Помимо самих данных расширения, в таблице хранятся записи-индексы. Они связывают идентификатор расширения с его составными частями. Это позволяет платформе эффективно собирать расширение в памяти при старте системы.
3. Версионность и кэширование: При внесении изменений платформа может сохранять промежуточные состояния. Это необходимо для обеспечения стабильности: если процесс обновления будет прерван, система должна иметь возможность откатиться к работоспособному состоянию.
4. Разделение данных: Если ваша база данных работает в режиме разделения (например, в модели SaaS или облаке), записи в ConfigCAS могут дублироваться или разделяться для разных областей данных, даже если используется один и тот же функционал расширения.

Формат данных и внутренняя структура

Выясним, в каком виде данные попадают в SQL. Если мы посмотрим на структуру таблицы ConfigCAS, то увидим поля для хранения бинарных данных (обычно это Image или VarBinary(max) в зависимости от версии SQL). Рассмотрим подробнее процесс упаковки:

Данные внутри этих полей сжаты алгоритмом zlib/deflate. Это стандартный подход для 1С, который используется и в основной таблице Config. Если распаковать эти данные, мы обнаружим структуру, практически идентичную формату файлов .cf или .cfe. Это древовидная структура объектов, описанная во внутреннем текстово-бинарном формате 1С. Внутри находятся описания метаданных, программный код модулей и сериализованные формы.

Каждая строка идентифицируется через колонку FileName. Имена файлов часто представляют собой GUID-подобные строки. Например, соответствие может выглядеть так:

-- Пример логики поиска (условно)
SELECT FileName, BinaryData 
FROM ConfigCAS 
WHERE FileName LIKE 'extension-guid-part%'

Связь между ConfigCAS и ConfigCASSave

Проанализируем механизм сохранения изменений. В архитектуре 1С всегда разделяются «редактируемая» и «исполняемая» конфигурации. Это правило работает и для расширений:

• ConfigCAS: Здесь лежат расширения, которые актуальны для базы данных в данный момент. Это то, что работает у пользователей прямо сейчас. Данные попадают сюда только после нажатия кнопки «Обновить конфигурацию базы данных».
• ConfigCASSave: Это временное хранилище. Когда программист открывает расширение в конфигураторе и вносит изменения, они сохраняются именно в эту таблицу. Пользователи этих изменений еще не видят.

Этот механизм позволяет безопасно вести разработку: пока вы не завершили отладку расширения в ConfigCASSave, основная рабочая среда в ConfigCAS остается неизменной.

Особенности очистки и обслуживания

Важно помнить, что при удалении расширения через интерфейс конфигуратора записи из ConfigCAS не всегда исчезают мгновенно. Рассмотрим причины:

1. Отложенное удаление: Платформа может помечать записи как неактивные, фактически удаляя их только при выполнении регламентных операций или полной реструктуризации.
2. Наличие в ConfigCASSave: Если вы удалили расширение из основной базы, но оно осталось в «сохраненном» виде, записи в связанных таблицах могут сохраняться.

Для оптимизации работы этой таблицы мы рекомендуем регулярно проводить тестирование и исправление информационной базы с установленными галочками очистки неиспользуемых данных. Это поможет поддерживать таблицу ConfigCAS в актуальном состоянии и удалит «мусорные» записи, которые могли накопиться в процессе активной разработки расширений.

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