Каталог решений - А по-моему, они одинаковые

«Стою на асфальте я в лыжи обутый…» Именно эта фраза крутилась у меня в голове на второй час ковыряния в базе одного из клиентов.

Суть истории такая: есть копия production базы клиента (развернутая в файловом варианте dt выгрузка с боевого сервера) и есть CF из test base с изменёнными объектами. При сравнении рабочей конфигурации с CF платформа пишет, что они идентичные, хотя открытие одного и того же модуля прямо из окна сравнения визуально показывает, что они различаются.

Коллега, принесший сие «чудо» утверждает, что «полтергейст» начался где-то с полмесяца назад, когда при накате изменений на рабочую базу упал сервер 1С. Базу из резервной восстанавливать не стали, т.к. после перезапуска она была вполне работоспособной и все проверки показали адекватное поведение.

Паранормальные явления начались спустя неделю после нескольких обновлений. У пользователей после проведения обновления объекты не менялись.

Сначала грешили на кэш. Путаницы добавило, что после чистки кэша действительно часть проблем ушла.

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

Итак, после того, как эта база попала наконец ко мне в руки, она была подвергнута все видам пыток тестирований, какие только можно было придумать (ТиИ, chdbfl, выгрузка/загрузка dt, выгрузка/загрузка cf, всевозможные манипуляции с Config и ConfigSave в SQL и т.п.). Не помогало ничего. 

Здесь моя статья разделится на две части:

1. Моё изначальное предположение (дабы сохранить смысл последовавших комментариев)
2. Разъяснение уважаемого awa, давшего техническое понимание ситуации

1. Предположение

Вспомнилось, что ещё в 8.2 в одном из релизов разработчиками декларировалось существенное увеличение производительности при операции сравнения конфигураций, в этом же релизе требовалась конвертация конфигурации для совместимости. Производительность сравнения действительно повысилась в разы, что уже тогда наталкивало на мысль на внедрении контрольных чисел (или хэшей) в структуру метаданных. Совместив эту информацию с поведением базы при ручном изменении объектов был сделан утвердительный вывод о присутствии и использовании неких контрольных величин (предположительно хэшей) в метаданных. Т.е. сравнение непосредственно самих объектов производилось исключительно при несовпадении сохраненных контрольных значений. Если же значения совпадали платформа априори считала, что объекты идентичны и необходимости в более подробном сравнении нет. Осталось только придумать способ групповой переинициализации хэшей для всех объектов, т.к. ручной способ «по одному объекту» для конфигурации на базе УТ11 был совершенно неприемлем.

И тут вспомнился один механизм платформы, который я практически никогда не применял в своей практике, тем не менее как нельзя кстати подходящий для данной ситуации. Речь идет о возможности выгрузить/загрузить объекты конфигурации в отдельные файлы (меню «Конфигурация», пункты «Выгрузить конфигурацию в файлы…» и «Загрузить конфигурацию из файлов…»

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

Итак, возвращаясь к исходной истории, могу сказать, что после проведения вышеописанной процедуры выявилось расхождение по целому ряду объектов. Устранив данные расхождения, мы добились полного восстановления работоспособности базы.

2. На самом деле

Комментарий (24) от awa:

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

При сравнении конфигураций 1С сначала сравнивает версии файлов, и если они равны, не делает дальнейшего сравнения. Если же версии не равны, то сравниваются между собой непосредственно файлы объектов. При этом нужно еще учитывать, что метаданные хранятся в конфигурации иерархически, в виде дерева. Поэтому, даже если версии двух конкретных файлов не равны, но версии файлов-родителей равны, то сравнение просто не дойдет до сравнения этих файлов, так как «обрубится» на сравнении родителей.

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

Советую прочитать комментарий полностью, т.к. помимо пояснения там ещё предложен альтернативный способ исправления. И если пожелаете поставить плюс данной статье, не забудьте поставить плюс и этому комментарию.

Кстати, упомянутые ошибки в механизме выгрузки/загрузки через файлы действительно имеют место быть, но преимущественно связаны с НФ-режимом конфигурации, т.к. часто некорректно выгружались именно формы с объектными ссылками, в УФ-режиме явных проблем я не наблюдал, т.к. управляемые формы довольно хорошо сериализируются. Тем не менее, соглашусь, что данный метод Вы применяете на свой страх и риск (впрочем, как и само использование продуктов 1С 🙂 ).

Желаю Вам не попадать в такие ситуации, но если уж попали, то вот вам на вооружение инструкция, как из неё выходить.

P.S. Буквально спустя дня два в точно такую же ситуацию попал другой мой коллега, причём конфигурация была другая (БП 3.0) и релиз платформы был из последних на тот момент. Так что ни от конфигурации, ни от версии платформы это не зависит (по крайней мере пока).