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

17.09.24

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

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

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

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

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

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


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

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

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

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

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

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

+10 –

См. также

Системы контроля версий для 1С-разработчиков.

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

Использования систем контроля версий — стандарт современной разработки. На курсе научимся использованию Хранилища 1С и GIT при разработке на 1С:Предприятие 8. Разберем подходы и приемы коллективной разработки, научимся самостоятельно настраивать системы и ориентироваться в них.

4900 руб.

29.06.2022    12613    106    4    

138
Хранилище дополнительных отчетов и обработок и запуск под пользователем для проверки отчетов

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

Хранилище дополнительных отчетов и обработок для групповой разработки.

4 стартмани

29.10.2024    656    2    MaxxiMiliSan    6    

2
Разветвленная разработка на хранилищах и файлах поставки

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

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

23.09.2024    4798    kraynev-navi    3    

26
Git vs Хранилище. Битва титанов?

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

Называть Git новой технологией – уже смешно, но для многих 1С-ников это действительно «новое и неизведанное». Расскажем о плюсах и минусах двух главных систем контроля версий в мире 1С: Git и хранилища.

17.09.2024    10101    Golovanoff    69    

26
Релиз каждый день – это тоже релиз!

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

Во многих командах незаслуженно забывают о том, что в базе меняются расширения (как от вендора, так и собственные) и внешние отчеты и обработки. Вплоть до того, что релиз происходит каждый день – меняются печатные формы, отчеты, обработки. Расскажем о том, как выгружать в Git не только изменения конфигурации рабочего контура, но и файлы внешних обработок и расширений.

05.09.2024    3873    ardn    12    

15
Почему заказчики любят EDT (+ GIT), а разработчики ненавидят?

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

Заказчики любят EDT+Git за прозрачность и контроль качества. А у разработчиков есть две основные причины не любить EDT – это тормоза и глюки. Расскажем о том, что нужно учесть команде при переходе на EDT+Git.

14.08.2024    9520    lekot    34    

8
Технология разветвленной разработки конфигураций 1С

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

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

05.08.2024    7503    sinichenko_alex    16    

26
Обновление OpenYellow

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

Про изменения и новинки в агрегаторе открытых проектов OpenYellow, которые появились с момента его создания: про портал, Github и Telegram

15.07.2024    4905    bayselonarrend    8    

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