Каталог решений - О синхронизации ИБ с проектом в EDT

О синхронизации ИБ с проектом в EDT

О синхронизации ИБ с проектом в EDT

В наличии

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

Категория:

Описание

Ни для кого не секрет, что при разработке в EDT больше всего раздражают незапланированные длительные операции, и очень часто появление сообщения (назовём его "печальным") вида:

 

Грустное сообщение

 

может вывести из себя, в особенности если вы чётко осознаёте бессмысленность потраченного времени на неё.

Первопричины появления такого сообщения могут быть разные, но как результат его изменённая, по отношению к связанному с проектом EDT конфигурация, непосредственно в конфигураторе.

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

В случае, приведённом выше операция, если проект класса ERP, даже на топовом оборудовании (Core i7, SSD, >16Gb RAM) может отнять около полутора часов на полную пересборку, причём она не пройдёт полностью автоматически: после длительного импорта и конвертации в формат EDT, чтобы добиться желаемой синхронности:

 

зеленогалка

 

нужно будет обновить конфигурацию ИБ и это будет тоже полная сборка.

Если говорить более конкретно, то моя патовая ситуация была такова, что я в EDT разрабатывал расширение для конфигурации ERP, а сама конфигурация была подключена к хранилищу 1С и была на железном, для меня, замке от того, что моя УЗ в репозитории 1С была только на чтение… Т.е. импорт то я бы сделал, но обновить конфигурацию ИБ не смог бы по определению, соответственно так как по отношению к проекту расширения основной проект не синхронизирован,  сборка обновления расширения производится не будет…

Надо отметить, что злая штука здесь в том, что несмотря на то, что захват объектов в хранилище не произведён, объекты метаданных (в отличии, когда импортирована конфигурация, к примеру, на поддержке с запретом изменений) лихо редактируются в EDT и "сюрприз" может поджидать совсем неожиданно, когда нужно будет запустить отладку… Тут небольшой совет: даже если вы не собираетесь ничего изменять в основном проекте — сделайте его совместным и сделайте один коммит всего проекта в вашем локальном репо — вы всегда  сможете откатить "случайные" или не очень изменения.

Возвращаясь к моему примеру, что я сделал, чтобы получить "печальное" сообщение:

  1. Открыл конфигуратор
  2. Получил изменения из хранилища, в котором было добавление предопределённого элемента в справочнике и два переименования других предопределённых элементов
  3. Обновил конфигурацию ИБ
  4. Закрыл конфигуратор
  5. В списке ИБ, для этой ИБ выбрал "Импортировать конфигурацию" и нажал в диалоговом окне кнопку обновить.

 

 

 

Что далее?

Далее всё. Выходом из этой ситуации поможет знание как устроен механизм синхронизации проекта EDT с информационной базой.

За заветную зелёную галку отвечает файл без расширения store, размещённый в служебном каталоге проекта Eclips’a:

<%1>\.metadata\.plugins\org.eclipse.core.resources\.projects\<%2>\com._1c.g5.v8.dt.platform.services.core\.default\infobase-synchronization\%3\SynchronizationData.store

Где:

  • %1 — путь к вашему workspace
  • %2 — имя вашего проекта как вы его видите в списке проектов панели навигатора 1С
  • %3 — UUID информационной базы, связанной с проектом %2, как он числится в файле
    • "%USER PROFILE%\AppData\Roaming\1C\1CEStart\ibases.v8i"

 

Содержимое файла, соответствующее зелёной галке, если его посмотреть в Notepad++ выглядит так:

 

 store

 

 

  • Если вы в EDT измените какие-либо объекты метаданных, затем закроете EDT и посмотрите содержимое, то пути к изменённым объектам, и связанных с ними для инкрементального обновления будут размещены через semicolon справа от последнего NUL, но запись  SYNCHRONIZED будет на месте.
  • А  вот если справа от последнего NUL не будет ничего, а вместо SYNCHRONIZED будет UNSYNCHRONIZED, то при попытке обновить конфигурацию ИБ у вас будет в любом случае полная выгрузка проекта в XML и полная сборка CF.

 Надо отметить, что и в первом и во втором случае в редакторе проекта вместо зелёной галки будет жёлтая *

До окончания сеccии EDT список изменённых объектов храниться в файле log, лежащим рядом со store, по закрытии сесcии EDT, данные из log’a переносятся в store, а сам файл удаляется.

Наверное, вы сейчас подумали: "Ха, так достаточно заменить это файл store на сохранённый и будет всё тип топ — прощай унылая звезда и здравствуй зелёная галка!" Да, если погасить EDT, заменить этот файл, затем запустить снова, то заветный статус синхронизации в редакторе проекта будет присутствовать… Но, не всё так просто…

Подобная махинация вас спасёт, если структура метаданных не была затронута, а именно — правки в модулях и возможно в текстах запросов СКД, возможно что-то ещё, но это что-то должно однозначно не изменять файл ConfigDumpInfo.xml который является неотъемлемой частью этого механизма.

Общее размещение файлов на картинке:

 Структура каталогов

 

После первоначального импорта ИБ "на замке" или подключенной к хранилищу я Вам настоятельно рекомендую запаковать содержимое каталога %3 (см описание выше) и положить в укромное местечко. Как только появится унылое окно, они вас спасут 🙂

Однако, вернёмся к насильственным методам убеждения EDT, что проект, лежащий в рабочей области точно соответствует конфигурации связанной с ним ИБ, если всё же конфигурация была изменена, в проект мы изменения импортировали, а обновлять ИБ не желаем или не можем.

  1. Получить из новой ИБ файл ConfigDumpInfo.xml . Сделать это можно следующим образом:
    1. По 14ю платформу включительно:
      %4\1cv8.exe"  DESIGNER /AppAutoCheckMode /S %5 | /F %5 [/WA -] [/N %6] [/ConfigurationRepositoryF %7 [/ConfigurationRepositoryN %8] /DumpConfigToFiles %9 /Out %10
    2. Начиная с 15й платформы добавился ещё параметр:
      %4\1cv8.exe"  DESIGNER /AppAutoCheckMode /S | /F %5 [/WA -] [/N %6] [/ConfigurationRepositoryF %7 [/ConfigurationRepositoryN %8] /DumpConfigToFiles %9 —configDumpInfoOnly /Out %10

Где:

  • %4 — Путь к выполнимому файлу 1С
  • %5 — путь к ИБ в виде сервер\ИБ для модификатора /S или путь в файловой ИБ если использован модификатор /F
  • %6 — пользователь ИБ
  • %7 — путь к репозиторию 1С, если ИБ подключена к нему
  • %8 — пользователь репозитория
  • %9 — каталог куда положить CofigDumpInfo
  • %10 — лог, посмотреть если что не так пошло
  1. Положить полученный ConfigDumpInfo.xml в служебный каталог эклипса
  2. Заменить файл store на ранее сохранённый.
  3. Запустить EDT и убедиться, что имплант прижился.

 

Где ещё это может быть полезно?

В групповой разработке. Ситуация, один разработчик начал работать над проблемой, но … Потребовалось быстро передать промежуточные результаты работы другому, который, естественно живёт в другом рабочем пространстве…

Надо отметить, что для проекта в групповой разработке местонахождения файлов синхронизации отлично:

 

 групповая структура

 

Т.е. в этом случае наша последовательность действий следующая:

  1. Если у первого (передающего) разработчика ИБ синхронизирована с рабочей областью, то он все результаты работы коммитит в ветку исправления/фичи и отправляет в совместный репозиторий. И передаёт ИБ другому разработчику (преемнику технического долга 🙂
  2. Помимо этого, первый разработчик закрывает EDT, архивирует содержимое каталога %3 включая структуру и так же передаёт второму разработчику
  3. Второй разработчик извлекает ту ветку, где были остановлены работы создаёт локальную ветку и присоединяет к ней в редакторе проекта информационную базу.
  4. Дожидается окончания обновления вторичных данных в прогрессе после извлечения (чекаута), после чего гасит EDT, находит каталог с присоединённой ИБ %3 у себя (идентификатор у нег естественно другой) и заменяет его содержимое на то, что отдал первый разработчик.
  5. Запускает EDT и проверяет — зеленогалка в редакторе проекта должна быть и при запуске отладки сборки проекта производиться не будет. Возможна некоторая задержка на сверку ConfigDumpInfo из присоединённой ИБ с тем, что подсунули в служебный каталог Эклипса… Небольшая для ERP на не топовом оборудовании (Core i3, HDD, 8 Gb RAM) — около 5 минут, на топовом и того меньше… Но это будет в десятки раз быстрее, чем полная сборка…

 

Вот собственно и всё, для многих, кто только начал работать с EDT это покажется китайской грамотой, но я очень надеюсь, что, в итоге, мои инструкции помогут вам сэкономить то, что невозможно вернуть — время.

has been added to your cart:
Оформление заказа