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

17.09.24

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

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

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

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

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

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


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

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

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

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

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

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

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

+13 –

См. также

Автоматическое обновление конфигурации из хранилища

Инструменты администратора БД Групповая разработка (Git, хранилище) Обновление 1С Системный администратор Программист 1С:Предприятие 8 1С:Комплексная автоматизация 2.х 1С:Библиотека стандартных подсистем Абонемент ($m)

Обработка, объединяющая в себе использование инструментов БСП по администрированию кластера серверов и запуска скриптов для автоматического обновления конфигурации из хранилища.

4 стартмани

17.11.2025    685    1    KovrovtsevAS    0    

7
Git на жестких 1С:ERP-проектах: быстрое внедрение без EDT

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

Проектная разработка в 1С живет в условиях жестких дедлайнов, меняющихся команд и нестабильных CI/CD. В статье показываем, как быстро и без лишних затрат внедрить Git на ERP-проектах, продать идею себе и команде и избежать типичных подводных камней. Разберем ветвление, подходы к командной работе, интеграцию с таск-трекерами и особенности тяжелых конфигураций.

04.09.2025    8341    bozo    42    

12
Плагин EDT для работы с хранилищем конфигурации 1С

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

Плагин, расширяющий функциональность EDT, предоставляя возможность работы с хранилищем конфигурации 1С без использования 1С:ГитКонвертер.

04.08.2025    7472    ZigRinat85    19    

41
Поставка расширения конфигурации с помощью команд строки запуска "1С:Предприятие", GIT, KDiff3

DevOps и автоматизация разработки Групповая разработка (Git, хранилище) Программист 1С:Предприятие 8 1С:Библиотека стандартных подсистем Абонемент ($m)

Позволяет проектировать и выполнять сценарии, состоящие из команд 1С, Git и CMD, а также решать конфликты слияния напрямую из 1С с помощью KDiff3. Предустановлен набор команд для автоматизации сборки CFE-файлов.

1 стартмани

29.07.2025    3827    6    gorsheninsn    6    

27
Работаем с GIT без хранилища и EDT

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

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

22.07.2025    8765    ktb    28    

39
Оптимизация работы с GIT

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

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

14.07.2025    3851    bborisko    0    

9
OneScript + EDT + GIT

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

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

11.06.2025    5416    AlexF1    4    

9
Автоматизация формирования и актуализации ветки типовых релизов для Git-репозитория EDT

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

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

21.05.2025    6811    vladimir_iclsoft    3    

22
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. Xershi 1531 18.09.24 20:59 Сейчас в теме
А как так вышло?
Я после глобального обновления снимаю бекап рабочей базы и заливаю в базу для разработки.
Ни разу с таким не сталкивался.
Была похожая ситуация когда вышло 10 обновлений и франч накатил их без обновления конфигурации поставщика. Но накатывание конфигурации поставщика решило проблему и такого как у вас не было.
В довесок, а не потеряет ли база данные после таких манипуляций! На копии конечно не страшно, но стоит об этом упомянуть!
smartcoder; +1 – Ответить
2. krash13 18.09.24 23:21 Сейчас в теме
(1) Ну например, есть гении, переносящие из дев контура в рабочий контур реквизиты и даже целые объекты ctrl-C ctrl-V или перетаскиванием
smartcoder; +1 – Ответить
3. Xershi 1531 19.09.24 12:06 Сейчас в теме
(2) ну тут конечно такое будет. Как говорится по рукам давать за такое. Поэтому за правило нужно взять разработка у себя а в рабочей только получать изменения.
zqzq; +1 – Ответить
4. user1852486 19.09.24 15:31 Сейчас в теме
(3) Судя по всему у вас один контур, я именно про два говорю, когда рабочее хранилище отдельно от разработки/теста.
+ – Ответить
5. Xershi 1531 19.09.24 16:30 Сейчас в теме
(4) ну это накладные расходы, такое можно позволить при наличии целой команды разных разработчиков.
+ – Ответить
6. vatkir 20 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 1531 23.09.24 14:31 Сейчас в теме
(6) это не глюк, а кеш.
+ – Ответить
13. vatkir 20 29.09.24 07:31 Сейчас в теме
(7) эм...нет, вы ошибаетесь, именно резные идентификаторы в двух конфигурациях, чистка кеша такое не лечит
+ – Ответить
14. Xershi 1531 29.09.24 13:24 Сейчас в теме
(13) возможно действительно глюк, стоит разработчикам отписать. Но по опыту такое поведение на 90% связано с кешем.
+ – Ответить
8. Wi5hMaCTeP 5 24.09.24 09:36 Сейчас в теме
Не проще пересоздать хранилище из прода (вообще всегда надо именно оттуда его создавать, имхо) и перезалить дев-базы бэкапом прода?
+ – Ответить
9. vatkir 20 25.09.24 06:59 Сейчас в теме
(8) конечно проще, но все объекты должны быть не захвачены, такое окно иногда трудно поймать
+ – Ответить
11. Wi5hMaCTeP 5 25.09.24 08:20 Сейчас в теме
(9) да, это нужно согласовывать с командой. Но, если вопрос стоит остро, я думаю не проблема согласовать остановку на пару часов. Делал такое не раз, на команде до 10 человек вообще проблем не возникает.
+ – Ответить
10. n_mezentsev 65 25.09.24 07:59 Сейчас в теме
Спасибо за метод, но, к сожалению, он не работает в случае, если есть другие отсутствующие/присутствующие Объекты (по крайней мере, они - насчет реквизитов не знаю). То есть при внедрении нового объекта в рабочую базу также сидишь и ждешь в свое окошко...
И вы забыли упомянуть важный факт. В тестовой базе удалятся данные, указанные в удаляемом реквизите. Добавьте, пожалуйста. Это, конечно, не серьезная проблема, но может быть болезненным - опять тестовые данные собирать. (это естественно, кстати, ведь в базе sql данные хранятся под особыми идентификаторами, позволяя нам динамически обновлять имя реквизита, но не удалять - восстанавливать вручную/объединением, конечно)
+ – Ответить
12. vatkir 20 29.09.24 07:27 Сейчас в теме
(10) Это в статье есть, см. последнее предложение. Насчёт тормозов если конфигурации различаются целыми объектами - логично.
+ – Ответить
15. n_mezentsev 65 22.10.24 09:35 Сейчас в теме
(10) Поправка, сравнение было долгим потому как один макет не отследил, при наличии различных добавленных реквизитов и даже объектов сравнение идет дольше, чем мгновенно, но совсем не долго:)
+ – Ответить
16. Сисой 88 04.04.25 15:05 Сейчас в теме
У нас два хранилища: дев и прод. Хранилище прода нужно для внесения в режиме динамики оперативных патчей и костылей (которые потом портируются в дев). К хранилищу прода подключена и прод-база.
Из дева в прод изменения накатываются через поставку релиза. 4 года - полет нормальный.
+ – Ответить
Для отправки сообщения требуется регистрация/авторизация