"Мгновенный" перенос конфигурации

Мгновенный перенос изменений конфигурации между копиями ИБ 8.*


Очень часто при разработке используется несколько копий базы одной конфигурации.

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


Дак вот все эти копии для плодотворной работы коллектива приходится обновлять каждый раз когда тестеры натыкаются на очередную по их мнению «не преодолимую ошибку«.

Немного напомню у том как это можно сделать стандартными методами

Есть два пути .. через распределенку, и через Владивосток.

Через распределенку все просто передаем изменения из главного узла в перефирийные.
Чем плох данный способ ..

  • Во первых нужно создавать план обмена.
  • Во вторых каждый раз при создании копии (не начального образа) переопределять главный узел.
  • Ну и читать каждый раз изменения из Xml файла, запуская вначале предприятие и потом конфигуратор.

Ну и через Владивосток это самый распространенный способ:

  1. Выгрузить конфигурацию (УПП 1.2.9 — 5 мин)
  2. Загрузить конфигурацию без сравнения (УПП 1.2.9 — 9 мин).
  3. Обновить конфигурацию (УПП 1.2.9 — 4 мин)

Итого: (5 + 13*n) где n— колличество баз.
О недостатках этого способа нужно говорить?

Есть еще один путь .. пользуюсь им давно не так давно но поражаюсь почему до этого все ходил мимо и не замечал таких простых вещей.

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

Теперь спустимся ну уровень ниже. Для того что передать изменения в конфигурацию нужно сделать записи в Таблицу ConfigSave. При чем не всей конфигурации (как при загрузке без сравнения), а только измененных. Измененной запись будем считать если дата изменения «Modified» ее в основной конфигурации больше чем в копии. Можно еще сравнивать по размеру ну я считаю что это лишнее.
Ну собственно записи добавляем следующим запросом в EM или Enterprise Integrator

В запросе нужно поменять только названия баз соответствующих вашим.

 

 

Имя БД
Описание
dogovor_81 Основная БД из которой передаем изменения конфигурации.
Dogovor81_Test Копия БД в которую нужно передать изменения конфигурации.


 

INSERT INTO Dogovor81_Test.dbo.ConfigSave
Select ConfigNew.* From dogovor_81.dbo.Config as ConfigNew
Left JOIN
Dogovor81_Test.dbo.Config as ConfigOld
ON ConfigNew.FileName = ConfigOld.FileName
Where ConfigNew.Modified>ConfigOld.Modified or ConfigOld.Modified is Null

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

  1. Запрос выполняет меньше 2 сек.
  2. Обновление ~~60 сек. записей значительно меньше.
  3. Устраняется колоссальная избыточность перезаписи одинаковых данных.

Ограничения:

  1. Перед выполнением запроса конфигурация в которую необходимо передать изменения должна соответствовать конфигурации БД.
  2. Разумеется только для серверного варианта.




 

12 Comments

  1. artbear

    Красиво 🙂

    ЗЫ блин, похоже, уже пора как-нибудь научиться пользоваться Интегратором 🙂

    Reply
  2. IronDemon

    А что будет при обычном сравнении-объединении после применения твоего способа?

    Reply
  3. awa

    Плюс однозначно! Но вообще-то для описанной ситуации (несколько баз с идентичными конфами) в 1С предусмотрен механизм хранилища, он же средство групповой разработки, он же система контроля версий. Хранилище много удобней и распределенки и уж тем более «Владивостока» 🙂 И в пакетном режиме можно базы обновлять — есть соответствующие ключи командной строки.

    Reply
  4. awa

    Кстати, если в новой конфигурации будет удалён какой-либо объект, например справочник? Насколько я понял из запроса, в обновляемой конфе он останется. Или 1С такую ситуацию отработает правильно?

    Reply
  5. BorovikSV

    Зачем огород городить? Есть же хранилище!

    Reply
  6. German

    (4) все ситуации будут отработаны стандартно.. аналогичны перечислинным вариантам.

    http://groups.google.ru/group/enterprise-integrator/browse_thread/thread/30d2c1b28661ef5f

    Reply
  7. German

    (5) я не против хранилища как раз наоборот, но хранилише в пурвую очередь необходимо для групповой разработки.

    Как раз наооборот для выполнения секудных операций в мне предлагаете подключить базы к хранилишу. а я предлагаю выполнить всего лишь один запрос.

    Reply
  8. Fynjy

    Вот ведь вопрос … При РБД прокатит такой перенос? Там помоему идет метка «изменения отправлены»- «изменения загружены». Или я ошибаюсь.

    ЗЫ: Идея гуд.

    Reply
  9. boggonzikov

    А для postgres подскажите запрос?

    Reply
  10. mrscylla

    boggonzikov порадовал (я случайно зашел в эту тему)

    На дворе 2010 год и «Хранилище конфигурации» и «Сервер хранилища конфигурации»

    😀

    Reply
  11. Трактор

    Жестокий способ. Автор знает толк в извращениях 🙂 А вечерами, наверное, развлекается гуляя по канату на двадцатиметровой высоте без страховки.

    Reply
  12. rasswet

    (9)если узнаете-маякните

    Reply

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *