Будут ли одинаковыми внутренние идентификаторы у копий реквизитов и как их узнать?

В процессе разработки на платформе 1С:Предприятие 8 часто возникает вопрос: как система понимает, что два объекта в разных конфигурациях — это один и тот же объект, даже если их имена различаются? Или наоборот, почему два реквизита с одинаковыми именами могут считаться платформой абсолютно разными сущностями? Все дело во внутренних идентификаторах (UUID). Разберем подробно, как они работают, что происходит при копировании реквизитов и какими способами можно увидеть эти скрытые данные.

Суть внутреннего идентификатора реквизита

Каждый объект метаданных в 1С (будь то справочник, документ или обычный реквизит) обладает уникальным внутренним идентификатором — UUID (Universally Unique Identifier). Это 128-битное число, которое генерируется платформой автоматически в момент создания объекта.

Важно понимать разницу между именем реквизита и его идентификатором:

• Имя (например, Реквизит1) — это строковый идентификатор для разработчика и кода. Оно может быть изменено в любой момент.
• UUID — это "паспорт" объекта. Он остается неизменным на протяжении всей "жизни" реквизита, даже если вы переименуете его десять раз.

Отвечая на основной вопрос: нет, при копировании реквизита его внутренний идентификатор не будет прежним. Платформа создаст абсолютно новый UUID для скопированного элемента. Рассмотрим подробнее, почему это происходит и на что влияет.

Что происходит при копировании реквизита (Ctrl+C / Ctrl+V)

Когда мы копируем Реквизит1 и получаем Реквизит2, платформа выполняет операцию создания нового объекта метаданных, копируя лишь его свойства (тип, длину, точность, синоним). Поскольку это новый объект, ему назначается новый уникальный UUID.

Проанализируем последствия этого процесса:

1. Реструктуризация базы данных: При обновлении конфигурации базы данных платформа увидит новый UUID и создаст в физической таблице SQL новую колонку (например, _Fld1234).
2. Сравнение и объединение: Если вы попытаетесь объединить две конфигурации, в одной из которых реквизит был создан вручную, а в другой — скопирован, система может не сопоставить их автоматически, так как их "паспорта" (UUID) различаются.
3. Разрыв связей в расширениях: Если расширение конфигурации "заимствовало" реквизит по его UUID, а вы удалили старый и создали новый с тем же именем, расширение "потеряет" этот объект.

Как узнать внутренний идентификатор реквизита

Существует несколько способов "вытащить" скрытый UUID объекта метаданных. Рассмотрим их от простых к более продвинутым.

Способ 1: Выгрузка конфигурации в файлы XML

Это самый надежный способ увидеть идентификаторы всех объектов сразу. Разберем его по шагам:

1. Откроем конфигуратор.
2. Выберем пункт меню Конфигурация — Выгрузить конфигурацию в файлы....
3. Укажем пустую папку и дождемся завершения процесса.
4. В целевой папке найдем XML-файл, соответствующий нашему объекту (например, Catalog.Справочник1.xml).
5. Откроем файл любым текстовым редактором.

Внутри файла мы увидим структуру XML. Идентификатор реквизита будет находиться в атрибуте uuid. Рассмотрим пример фрагмента такого файла:

<ChildObjects>
    <Attribute uuid="a1b2c3d4-e5f6-7a8b-9c0d-e1f2a3b4c5d6">
        <Properties>
            <Name>Реквизит1</Name>
            <Type>
                <v8:Type>xs:string</v8:Type>
            </Type>
        </Properties>
    </Attribute>
</ChildObjects>

Способ 2: Программный доступ через встроенный язык

Если нам нужно узнать UUID реквизита непосредственно во время работы программы или для целей автоматизации, мы можем воспользоваться методом UUID() объекта метаданных. Проанализируем пример кода, который выводит идентификатор реквизита справочника:

// Получаем объект метаданных реквизита
РеквизитМетаданные = Метаданные.Справочники.Справочник1.Реквизиты.Реквизит1;

// Извлекаем UUID
ВнутреннийИдентификатор = РеквизитМетаданные.UUID();

// Выводим результат
Сообщить("UUID реквизита: " + Строка(ВнутреннийИдентификатор));

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

Роль идентификаторов при сравнении и объединении

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

1. Сравнение произвольных конфигураций: В этом случае платформа в первую очередь пытается сопоставить объекты по имени. Если имена совпадают, объекты считаются идентичными. Если по имени пара не найдена, система пробует сопоставить их по UUID (что актуально для переименованных объектов).
2. Сравнение родственных конфигураций: Например, при сравнении основной конфигурации с конфигурацией базы данных или хранилищем. Здесь сопоставление идет только по UUID. Имя игнорируется. Именно поэтому, если вы переименуете реквизит, 1С поймет, что это тот же самый реквизит, и просто переименует колонку в SQL без потери данных.
3. Сравнение с конфигурацией поставщика: Это наиболее сложный механизм, где UUID играют ключевую роль в отслеживании изменений, внесенных разработчиком в типовое решение.

Практическое значение: переименование против удаления

Рассмотрим ситуацию: вам нужно изменить назначение реквизита. У вас есть два пути:

• Путь А: Изменить имя существующего реквизита Реквизит1 на НовоеНазначение. В этом случае UUID сохраняется. При обновлении базы данных данные в этой колонке у существующих элементов сохранятся.
• Путь Б: Удалить Реквизит1 и создать новый реквизит НовоеНазначение. В этом случае создается новый UUID. Платформа воспримет это как удаление старой колонки (данные будут стерты!) и создание новой пустой колонки.

Важный совет: Если вы хотите "перенести" реквизит из одной конфигурации в другую (неродственную) так, чтобы 1С считала их "родственниками", единственный способ сделать это — ручная правка UUID в XML-файлах выгрузки перед загрузкой конфигурации. Однако это считается "черной магией" и должно выполняться с осторожностью.

Связь с физическими таблицами СУБД

Хотя UUID метаданных напрямую не используется как имя колонки в SQL, связь между ними жесткая. Платформа хранит таблицу соответствий в системных таблицах базы данных (DBSchema). Для просмотра соответствия имен в 1С и имен в SQL можно использовать функцию:

СтруктураХранения = ПолучитьСтруктуруХраненияБазыДанных("Справочник.Справочник1");
// В полученной таблице значений будут колонки ИмяПоля и ИмяТаблицыХранения

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