Чиним долгое сравнение конфигурации

17.09.24

Разработка - Групповая разработка (Git, хранилище)

Как исправить медленное сравнение конфигурации с файлом cf, сохраненным из хранилища.

Если вы сохраняете конфигурацию из подключенной к хранилищу базы для разработки в файл "хранилище.cf", затем его сравниваете с боевой базой и у вас всё тормозит, значит реквизиты с одинаковым именем в боевой базе и в хранилище имеют разные GUID. Чтобы это исправить, надо:

1. Выполнить загрузку конфигурации из файла "хранилище.cf" в боевую базу данных, отказаться от обновления.

2. Нажать "Конфигурация базы данных" - "Сравнить, объединить с конфигурацией БД".

3. Увидеть какие реквизиты удалились, какие создаются (у них будет одно имя, но различается внутренний GUID), записать список этих реквизитов. Пример - см скриншот.


4. В боевой базе данных вернуться к конфигурации базы данных.

5. Сохранить конфигурацию из боевой базы в файл "боевая.cf". Боевая база больше не нужна.

6. В подключенной к хранилищу базе для разработки захватить объекты, удалить все записанные ранее реквизиты.

7. Сравнить с файлом "боевая.cf". Добавить ранее удаленные реквизиты. Они добавятся с теми GUID, которые имеют в боевой базе.

Всё, теперь если опять сохранить файл "хранилище.cf" и сравнить в боевой базе то сравнение будет работать быстро, так как теперь совпадают не только видимые имена реквизитов, но и их внутренние идентификаторы. Единственное, из этих реквизитов удалятся все данные в базе для разработки.

Вступайте в нашу телеграмм-группу Инфостарт

cf боевая база хранилище тормоза

См. также

Групповая разработка (Git, хранилище) Программист Бесплатно (free)

Разберем, как организовать работу с GIT, не покидая конфигуратор, и зачем может понадобиться автономный сервер. Вы узнаете о скриптах, которые автоматизируют взаимодействие с GIT прямо из 1С, а также о методах сборки / разборки обработок и расширений «на лету», которые значительно ускоряют процесс разработки и совместной работы.

22.07.2025    2661    ktb    16    

28

Групповая разработка (Git, хранилище) Системный администратор Программист Бесплатно (free)

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

14.07.2025    792    bborisko    0    

8

Групповая разработка (Git, хранилище) EDT OneScript Программист 1С v8.3 Бесплатно (free)

В данной публикации рассматривается пример реализации скрипта, который автоматизирует получение ветки из GIT репозитория и обновление конфигурации, если разработка проекта ведется в EDT.

11.06.2025    2019    AlexF1    4    

7

DevOps и автоматизация разработки Групповая разработка (Git, хранилище) EDT Программист 1С v8.3 Бесплатно (free)

В процессе использования 1С:EDT и репозитория Git для обновлений релизов доработанных конфигураций появилась необходимость в регулярной загрузке конфигураций от вендора 1С в Git-репозиторий. Описанное в статье решение позволяет автоматизировать эту операцию и может быть полезным специалистам, занимающимися обновлениями с использованием 1C:EDT+Git

21.05.2025    3284    vladimir_iclsoft    3    

20

Групповая разработка (Git, хранилище) Обновление 1С Программист 1С v8.3 Россия Бесплатно (free)

Внедряем проверку новых версий прямо в расширение. Оповещайте о новых версиях и показывайте пользователям список изменений. Для разработчиков, которые хотят сэкономить время и повысить лояльность клиентов!

05.02.2025    4937    Nonik    10    

18

Групповая разработка (Git, хранилище) Программист Руководитель проекта 1С v8.3 1C:Бухгалтерия Бесплатно (free)

Когда в хранилище одновременно разрабатывают несколько команд, сортировка сделанного и несделанного при формировании релиза и проведение code review по задачам превращаются в непроходимый квест. В таких случаях нужен бранчинг. Расскажем об опыте перехода на новую схему хранения кода для ИТ-департамента.

23.09.2024    9346    kraynev-navi    3    

27
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. Xershi 1540 18.09.24 20:59 Сейчас в теме
А как так вышло?
Я после глобального обновления снимаю бекап рабочей базы и заливаю в базу для разработки.
Ни разу с таким не сталкивался.
Была похожая ситуация когда вышло 10 обновлений и франч накатил их без обновления конфигурации поставщика. Но накатывание конфигурации поставщика решило проблему и такого как у вас не было.
В довесок, а не потеряет ли база данные после таких манипуляций! На копии конечно не страшно, но стоит об этом упомянуть!
smartcoder; +1 Ответить
2. krash13 18.09.24 23:21 Сейчас в теме
(1) Ну например, есть гении, переносящие из дев контура в рабочий контур реквизиты и даже целые объекты ctrl-C ctrl-V или перетаскиванием
smartcoder; +1 Ответить
3. Xershi 1540 19.09.24 12:06 Сейчас в теме
(2) ну тут конечно такое будет. Как говорится по рукам давать за такое. Поэтому за правило нужно взять разработка у себя а в рабочей только получать изменения.
4. user1852486 19.09.24 15:31 Сейчас в теме
(3) Судя по всему у вас один контур, я именно про два говорю, когда рабочее хранилище отдельно от разработки/теста.
5. Xershi 1540 19.09.24 16:30 Сейчас в теме
(4) ну это накладные расходы, такое можно позволить при наличии целой команды разных разработчиков.
6. vatkir 18 23.09.24 13:46 Сейчас в теме
(1) Вариант из статьи получился так: в базе для разработки надо переименовать Реквизит1 в Реквизит2, затем создать новый Реквизит1, затем на бой перенести не Загрузкой конфигурации, не подключением боя к хранилищу, а Сравнением объединением. Итог:
В хранилище:
- GUID1 = Реквизит2
- GUID2 = Реквизит1
В боевой:
- GUID1 = Реквизит1 (так и было изначально, сравнение объединение ничего не переименовало)
- GUID2 не существует (так как при сравнении система решила что Реквизит1 уже есть, хоть и с другим GUID, значит ничего не добавляем)
- GUID3 = Реквизит2 (новый GUID сгенерирован в момент добавления Реквизита2 при Сравнении объединении, т.к. GUID1 уже занят Реквизитом1)

Кстати это может потянуть за собой интересный глюк. Если в форму списка вывести Реквизит2. В базе хранилища отображается Реквизит2, в боевой в том-же элементе формы - Реквизит1. Пока не выполнишь действия из статьи починить этот сбой невозможно. Ну или как вы написали копию боевой взять и в ней кодить, но хранилище тогда заново надо создавать, т.к. в нём глюк сохранится.
7. Xershi 1540 23.09.24 14:31 Сейчас в теме
13. vatkir 18 29.09.24 07:31 Сейчас в теме
(7) эм...нет, вы ошибаетесь, именно резные идентификаторы в двух конфигурациях, чистка кеша такое не лечит
14. Xershi 1540 29.09.24 13:24 Сейчас в теме
(13) возможно действительно глюк, стоит разработчикам отписать. Но по опыту такое поведение на 90% связано с кешем.
8. Wi5hMaCTeP 5 24.09.24 09:36 Сейчас в теме
Не проще пересоздать хранилище из прода (вообще всегда надо именно оттуда его создавать, имхо) и перезалить дев-базы бэкапом прода?
9. vatkir 18 25.09.24 06:59 Сейчас в теме
(8) конечно проще, но все объекты должны быть не захвачены, такое окно иногда трудно поймать
11. Wi5hMaCTeP 5 25.09.24 08:20 Сейчас в теме
(9) да, это нужно согласовывать с командой. Но, если вопрос стоит остро, я думаю не проблема согласовать остановку на пару часов. Делал такое не раз, на команде до 10 человек вообще проблем не возникает.
10. n_mezentsev 60 25.09.24 07:59 Сейчас в теме
Спасибо за метод, но, к сожалению, он не работает в случае, если есть другие отсутствующие/присутствующие Объекты (по крайней мере, они - насчет реквизитов не знаю). То есть при внедрении нового объекта в рабочую базу также сидишь и ждешь в свое окошко...
И вы забыли упомянуть важный факт. В тестовой базе удалятся данные, указанные в удаляемом реквизите. Добавьте, пожалуйста. Это, конечно, не серьезная проблема, но может быть болезненным - опять тестовые данные собирать. (это естественно, кстати, ведь в базе sql данные хранятся под особыми идентификаторами, позволяя нам динамически обновлять имя реквизита, но не удалять - восстанавливать вручную/объединением, конечно)
12. vatkir 18 29.09.24 07:27 Сейчас в теме
(10) Это в статье есть, см. последнее предложение. Насчёт тормозов если конфигурации различаются целыми объектами - логично.
15. n_mezentsev 60 22.10.24 09:35 Сейчас в теме
(10) Поправка, сравнение было долгим потому как один макет не отследил, при наличии различных добавленных реквизитов и даже объектов сравнение идет дольше, чем мгновенно, но совсем не долго:)
16. Сисой 88 04.04.25 15:05 Сейчас в теме
У нас два хранилища: дев и прод. Хранилище прода нужно для внесения в режиме динамики оперативных патчей и костылей (которые потом портируются в дев). К хранилищу прода подключена и прод-база.
Из дева в прод изменения накатываются через поставку релиза. 4 года - полет нормальный.
Оставьте свое сообщение